id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc	phab_field
117	add CxxTest	Jan Wassenberg	Jan Wassenberg	"Background: using an existing Unit/self-test framework is deemed helpful (see 2006-05-27 meeting)
Chiefly based on [http://www.gamesfromwithin.com/articles/0412/000061.html evaluation], we choose [http://cxxtest.sourceforge.net/ CxxTest] as unit testing framework. 

Basic usage:
 * self-tests are separate Cpp files that contain only the test code. (splitting is necessary so that cxxtestgen doesn't have to parse the entire codebase)
 * they are stored in a tests subdir of the source directory (simplifies finding the relevant test file for purposes of editing it)
 * a workspace generated by premake enumerates all test files, uses custom build step to generate the actual test code, and then links it all into a separate program that runs all tests. Note: separating test code from the main PS executable has several advantages as [http://www.wildfiregames.com/forum/index.php?showtopic=10018&pid=171251&st=0&#entry171251 documented]
 * only running certain tests will be possible (shortens iteration time when only editing one module).

TODO:
 * ~~add !CxxTest to SVN~~
 * ~~generate workspace for the test program (via premake)~~
 * ~~move all existing tests over to that~~
 * ~~add squelchNextError feature, use it in string_s test~~
 * ~~make sure all tests run successfully~~
 * ~~filtering: modify(/replace/subclass) !TestRunner and change its runWorld() so that it filters by the !SuiteDescription.testName().~~

I think we can forget the filtering idea. First, the self-test error messages are printed via debug output, so (currently) the test executable needs to be run from within VS for them to be seen. This makes cmdline params much less useful. Also due to cxxtest design (no capability for filtering/stopping tests in a Listener), we'd have to hack cxxtest itself and pass argv through the testroot->GUIrunner->runWorld, which isn't so nice.

Also, the tests now actually work and are fine for a quick test before committing. If they need to really be run often (e.g. a quick test after every compile), it is easy to disable lengthy tests (simply prepend their test_* method name with something else).

Anyone disagree or want to see the filtering after all?"	task	new	Should Have	ASAP	Core engine		test