Jump to: navigation, search

Cppunit effort

1,865 bytes added, 19:21, 2 April 2018
FlightGear. </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Mar 5th, 2018
|added = Mar 5th, 2018
|script_version = 0.36
== Why Cppunit ==
The benefit of using an established and well tested test suite framework, rather than writing and maintaining our own framework, is that you have a clear separation of the framework maintainer and the test writers. The complexity is solely at the feet of the framework maintainer. However once CppUnit is included in the 3rdparty/ directory and the framework is established, the job of the framework maintainer is done. For my project relax, the complex code for the framework has essentially been untouched since 2006. Well, apart from some superficial refactoring and cleaning, and addition of the GUI test category in 2011. For the test writer, the advantage is the simplicity of test writing. They do not need to worry about the complexity of the framework implementation. They only need to write a setUp() function, the test*() code, and a tearDown() function to clean up (setUp and tearDown are optional). No knowledge of CMake is required. And they don't have to chase down all the sources required to build the binary. The protected execution of the setUp() and test*() functions is also a major advantage. I think this simplicity for test writers would make it easier for more potential developers to learn about the fgfs internals. They could start contributing to fgfs by writing unit or system/functional tests to learn about the fgfs internal design. If we had good test coverage, then you could say that all new developments need to come with one or more tests. That is how I do things. <ref>{{cite web
|url =
|title = <nowiki> Re: [Flightgear-devel] RFC: Working on a testing strategy for
FlightGear. </nowiki>
|author = <nowiki> Edward d'Auvergne </nowiki>
|date = Mar 5th, 2018
|added = Mar 5th, 2018

Navigation menu