[cybop-developers] CMake and UnitTests

[Enrico Gallus]

Hi Christian,

I put the ideas about the parsing of the CYBOI code to generate the API on my 
ToDo-List.

The project is already quite huge, I totally understand that there exists a lot 
of points of interest where to improve or add new functionality.
I absolutely don’t want to thwarts your plans by creating the issues and asking 
a lot of questions.

So i will dig into CMake, CTest and CPack a little bit. I gathered already some 
questions.

>Is it possible to realise libraries (dynamic/static) with CMake?
CMake is quite comfortable, creating libraries is straight forward. Please have 
a look here.
https://cmake.org/cmake/help/v3.0/command/add_library.html

I use CMake at the moment on my local computer and i have to say, that the 
compiling time improved a lot.
There is just one file I will commit. It contains all the information about 
what to build and what to pack.
All files which will be created by CMake are outside of the src-directory 
create in a temp folder. So it will not pollute the src-directory at all.

>Just some wishes:
>- it should work without errors before removing auto tools scripts
It works for me on the mac after installing cmake, i will commit the files, 
could you check if it works for you as well? A feedback is highly appreciated!
>- it should be easier, at least not more complicated than autotools
I’m absolutely not familiar with the autotools to be honest, but the cmake 
configuration is in my opinion quite easy to understand.
>- please keep the "src/" directory free from CMake files, if possible
Should be no problem
>- put them in a new directory "build/" instead (or something similar)
The one configuration files is placed in the root directory
>- put generated distributable packages or installers into "dist/“
this was quite a bit complicate. the platform dependent package is 
automatically deployed to dist now (.sh + tar.gz) just using cpack-command 
(zip, deb-package and other opportunities are possible easily)
>- ask me back once more on any unclearities
- at the moment the release package only contains the cyboi-binary. i guess 
there belong more to the release.
- copyright information and a lot of other configurations are possible 
(https://cmake.org/Wiki/CMake:CPackConfiguration)
- all directories or files which should be added needs to be set in the 
configuration using the INSTALL command
- please let me know how you would like to have the release and i will try to 
adjust the configuration that it will suit your process

Here is the configuration file, i created so far and which works perfectly for 
me. I think most of the parts are self-explaining. Don’t hesitate to ask if any 
question arise.

# --- CMake configuration --- #
# set minimum required cmake version
cmake_minimum_required(VERSION 3.8.0)

# set project name
project(cyboi)

# set output directory to controller-subdirectory
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/src/controller)

# define the binary to be create by make
add_executable(${PROJECT_NAME} ${PROJECT_SOURCE_DIR}/src/controller/cyboi.c)

# --- CPACK Configuration --- #

# set the version information
SET(CPACK_PACKAGE_VERSION_MAJOR "0")
SET(CPACK_PACKAGE_VERSION_MINOR "19")
SET(CPACK_PACKAGE_VERSION_PATCH "0")

# add the binary to the release
INSTALL(FILES ${CMAKE_CURRENT_SOURCE_DIR}/src/Controller/cyboi
              DESTINATION .)
# pack it to the dist directory
SET(CPACK_TOPLEVEL_TAG ../dist)

# activate CPack
include(CPack)

the following steps on the console needs to be done in the root-directory:

1. cmake . # create makefiles
2. make # create cyboi binary
3. cpack # created release package

If you are satisfied with CMake we can get ride of the 
makefiles/autotool-scripts later on.

Referring the testing:
I already had a deeper look into the implemented tests. I hope you don’t mind 
if I write you, why I think that the way how it is implemented should be 
improved.

1. Fast feedback on where is what broken (the traffic light system on unit 
tests)
I have seen plenty of prints in the unit tests you wrote, which are printing 
the result on the screen, this will not lead to an easy overview on where is 
what broken. Instead it is necessary to know the tests and to read all the 
output in detail. This is time consuming and probably frustrating. Rather than 
using prints, tests should fail if an expected value does not equal with the 
actual one. This should be improved, either by using asserts (i really don’t 
recommend this, there is no good feedback possible) or another framework which 
supports this easily

2. testing unit’s rather than integration
Looks like that most of the tests are integration tests, they are using several 
parts of the program, which will easily lead to issues when changing the 
program. Rather than testing processes, unit’s should be tested.

3. Connected with the source
I think it would be better to exclude the tests from the source. This way it 
will not be contained in the binary. A second advantage of the separation would 
be that it is not necessary to adjust the tester.c all the times tests are 
added or removed. Using the current approach will create a lot of code which 
needs to maintained.

4. automatic execution
CTest would allow to execute all defined tests and also create some dashboard 
for code-coverage results and so on. As far as i understand the structure how 
it is at the moment, can’t be easily integrated into CTest.

Proposal:
1. Extracting the tester-directory out of the src directory, to e.g. tests
2. Putting the classes into a src similar folder structure under tests.
3. rewrite the tests to use some proper mechanism to fail when expected != 
actual
4. integrate the tests to CTest

I am eager to know what you think about the proposal.

Greetings
Enrico