Opened 16 years ago
Closed 10 years ago
#311 closed task (fixed)
Setting up CTest environment
Reported by: | bknecht | Owned by: | nobody |
---|---|---|---|
Priority: | major | Milestone: | Version 0.3 Codename: Castor |
Component: | Cmake | Version: | |
Keywords: | CMake, CTest, unit test | Cc: | |
Referenced By: | References: |
Description (last modified by bknecht)
CTest
Since we use CMake as building system it is maybe a good idea to use CTest for unit testing. All large project have got unit tests to assure a code change has not broken any functionality in the existing code. While compiling with CMake CTest will test if all unit tests succeeded and report any broken functionality immediately. This is vital to have bug free code and no mess.
As the Orxonox code gets clearer and we introduce less hacks, testing proper functionality should be the next step.
Unfortunately writing unit test will take a lot of time and every developer will have to do this. Since it is used anyway by all larger projects, this seems to be worth doing despite the loss of time.
Task
This task is to set up the CTest environment (which includes the Dashboard of course) and to test it with some unit tests. Documentation on how to write unit tests and maybe even a small presentation for the developers about unit testing as this is a great-to-know thing (if not a must know) for a developer in the industry.
Start with the CTest documentation here.
Change History (5)
comment:1 Changed 16 years ago by bknecht
comment:2 Changed 16 years ago by bknecht
- Description modified (diff)
comment:3 Changed 16 years ago by bknecht
Check out the boost library as there seems to be additional helpers for unit tests. But I don't know if they are usable.
comment:4 Changed 16 years ago by rgrieder
Actually, the boost testing framework is quite large… It might be very helpful once you understand it.
There is a testing option in our CMake project for traffic testing, but not very much more. I'm going to put the testing part (just a few lines) into cmake/Testing.cmake to stress the fact that is task still to be done.
comment:5 Changed 10 years ago by landauf
- Resolution set to fixed
- Status changed from new to closed
was implemented 1-2 years ago (with gtest and gmock to write tests, ctest to run them, and an experimental hudson installation for continuous integration of the tests)
Some of you may remember, that Bensch once introduced unit testing and even wrote such a test. Unit testing hasn't been looked upon since, so I brought it up here with a ticket.
Note that this has nothing to do with the game, but rather if the maintainability of the code. Breaking a test is a very good warning, before a change might break the game.