[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cybop-developers] CMake and UnitTests
From: |
Enrico Gallus |
Subject: |
[cybop-developers] CMake and UnitTests |
Date: |
Sun, 5 Mar 2017 23:08:32 +0900 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [cybop-developers] CMake and UnitTests,
Enrico Gallus <=