| 6 | | MoleCuilder is by now a quite complex piece of code. as of this writing, it has around 90k lines of code and about 700 modules. I.e. the code has lots of cross references, lots of functions are need there and then also quite somewhere else. Hence, if you change the inner workings of one function, keeping its signature, it will compile, but most likely these functions somewhere else will not continue working as before. |
| | 6 | MoleCuilder is by now a quite complex piece of code. As of this writing, it has around 90k lines of code and about 700 modules. I.e. the code has lots of cross references, lots of functions are need there and then also quite somewhere else. Hence, if you change the inner workings of one function, maintaining its signature, it will compile, but most likely these functions somewhere else will not continue working as intended as they did before. |
| 65 | | On how to write a testsuite test, we refer you to these files to get a notion and [http://www.gnu.org/software/hello/manual/autoconf/Writing-Testsuites.html#Writing-Testsuites here] to have a reference of the possible autotest commands at hand. The scheme is always the same basically: |
| | 65 | Input and output files are stored in the subfolders of [source:tests/regression]. Each specific '''testsuite-....at''' has its own folder called alike. Have a look at '''testsuite.at''' wherefrom '''testsuite''' is constructed bu autotools. It only contains ''m4_include''s to all the test parts. |
| | 66 | |
| | 67 | These folders contain again folders with cardinal numbers, in each a '''pre''' and a '''post''' folder. '''pre''' contains input and '''post''' contains output files to test against. The numbers are arbitrary and are unique to the specific test. |
| | 68 | |
| | 69 | On how to write a testsuite test, we refer you to one of these '''.at''' files to get a notion and [http://www.gnu.org/software/hello/manual/autoconf/Writing-Testsuites.html#Writing-Testsuites here] to have a reference of the possible autotest commands at hand. The scheme is always the same basically: |
| 76 | | where ''<return value>'' is some number the code returns to indicate everything worked fine. |
| | 80 | where ''<return value>'' is some number the code returns to indicate everything worked fine. The global theme is specified only once per '''.at''' file, file ''AT_SETUP'' and ''AT_CLEANUP'' sort of embrace every specific test that you want to do. |
| | 81 | |
| | 82 | Note that testing the undo/redo-functionality of an Action is always placed into two extra tests, same small theme only with '''with Undo/Redo''' added. |
| | 83 | |
| | 84 | So, what to do step by step: |
| | 85 | 1. Pick the '''testsuite-....at''' file that you think your Action fits best. |
| | 86 | 1. Create your own folder within one of the subfolder list above. E.g. if 1 to 5 are used, take 6. Therein, create folders '''pre''' and '''post''' |
| | 87 | 1. In '''pre''' place all the inputs files your tests needs. In '''post''' place all the outputs files as you expect your Actions to produce (note: if you create them via a different manner than by just calling your Action and before you actually create the Action, even better so. If not, ''each'' of the stored output files should have been tested by some other means (visually at the very least).) |
| | 88 | 1. Add an setup/cleanup section to the chosen '''.at''' file, place ''AT_CHECK''s inside with calls to molecuilder and your action and some fgrep for specific messages of the molecuilder run and/or diff comparing the output files. |
| | 89 | |
| | 90 | Done. Test via '''make check''' which will also re-create the '''testsuite''' script. |
| | 94 | Unit tests are written using the [http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] testing framework. |
| | 95 | |
| | 96 | Have a look at subfolders called ''unittests'' in [source:src]. These folders containing the unit test soure code are located in the folders with the associated ''component'' or unit to test. Hence, they are also refered to as component tests and this is also their main intention: ''Testing small components of the big code for its specific functionality.'' |
| | 97 | |
| | 98 | Let us take the '''!SingletonUnitTest''' as an example, located in [source:src/Patterns/unittests] that tests correct implementation of the Singleton pattern in [source:src/Patterns/Singleton_impl.hpp]. The unit test consists of the following files: |
| | 99 | * source file with the test implementation, e.g. [source:src/Patterns/unittests/SingletonTest.cpp] |
| | 100 | * header file with the test definition, i.e. the class containing the test and all test functions to call, , e.g. [source:src/Patterns/unittests/SingletonTest.hpp] |
| | 101 | * [source:src/unittests/UnitTestMain.cpp] with the main function calling the unit test runner. |
| | 102 | * additional lines in '''Makefile.am''' to mark the small program as a test and to define the program to consist of your source, header and the !UnitTestMain.cpp file. |
| | 103 | |
| | 104 | Writing a new unit test then consists of writing the source and the header file, where you should guide yourself by the already present files. ''Naming convention'' is usually to suffix the name with '''!UnitTest''', e.g. '''!SingletonUnitTest.cpp'''. |
| | 105 | |
| | 106 | The test class should be named in a similar manner and has the following look: |
| | 107 | {{{ |
| | 108 | class SingletonTest : public CppUnit::TestFixture |
| | 109 | { |
| | 110 | CPPUNIT_TEST_SUITE( SingletonTest ); |
| | 111 | CPPUNIT_TEST ( blaTest ); |
| | 112 | CPPUNIT_TEST ( blablaTest ); |
| | 113 | CPPUNIT_TEST_SUITE_END(); |
| | 114 | |
| | 115 | public: |
| | 116 | void setUp(); |
| | 117 | void tearDown(); |
| | 118 | |
| | 119 | void blaTest(); |
| | 120 | void blablaTest(); |
| | 121 | }; |
| | 122 | }}} |
| | 123 | |
| | 124 | It inherits CppUnit::!TestFixture and defines it as a TEST_SUITE via the initial macros which also give the test functions to call. Below the test functions are defined along with ''setUp()'' and ''tearDown()'' which embrace the call of each test function, i.e. which create a common test environment for each test function, by allocating some memory, setting some stuff and cleaning up in the end again. |
| | 125 | |
| | 126 | See the [http://cppunit.sourceforge.net/doc/lastest/cppunit_cookbook.html CppUnit Cookbook] for a guide on how to write these tests. |
