| version 1.2 | | version 1.3 |
|---|
| | |
| Crossfire uses the 'check' C automated testing framework available at | | Crossfire uses the 'check' C automated testing framework available at |
| http://check.sourceforge.net | | http://check.sourceforge.net |
| The presence of this framework at compile time is not required but is STRONGLY | | The presence of this framework at compile time is not required but is STRONGLY |
| recommanded for developpers. You should not commit changes to the CVS if they | | recommended for developpers. You should not commit changes to the CVS if they |
| are not unit tested. In fact you should even write you new test before writing | | are not unit tested. In fact you should even write your new test before writing |
| the change. | | the change. |
| | | |
| Organization | | Organization |
| | |
| +-bugs ** contains test of known bugs (fixed and opened) | | +-bugs ** contains test of known bugs (fixed and opened) |
| | +-bugtrack ** Each file has the number of associated sourceforge bug id | | | +-bugtrack ** Each file has the number of associated sourceforge bug id |
| | | +-bug_<id>.c | | | | +-bug_<id>.c |
| | +-unrelated ** Bugs that for a reason or another where not referenced on sf | | | +-unrelated ** Bugs that for a reason or another were not referenced on sf |
| +-functional ** contains all functional tests with structure of tested code | | +-functional ** contains all functional tests with structure of tested code |
| | +-common | | | +-common |
| | +-socket | | | +-socket |
| | |
| | +-crossedit | | | +-crossedit |
| | +-general ** put here func test not in previous func categories | | | +-general ** put here func test not in previous func categories |
| +-plugins | | +-plugins |
| //structure still tonow be defined | | //structure still to be defined |
| | | |
| All source file having tests in them should be named test_*.c | | All source file having tests in them should be named test_*.c |
| | | |
| | |
| when test/unit is complete, each function of crossfire will be tested at least | | when test/unit is complete, each function of crossfire will be tested at least |
| once. | | once. |
| | | |
| Note: because crossfire make heavy use of macros, macros must be considered as | | Note: because crossfire makeis heavy use of macros, macros must be considered as |
| function and so must be unit tested too. Because macros are define in .h file, | | function and so must be unit tested too. Because macros are defined in .h file, |
| the unit test should have the form test_xxx for testing xxx.h. All unit tests | | the unit test should have the form test_xxx for testing xxx.h. All unit tests |
| for .h files goes to test/headers | | for .h files go to test/headers |
| | | |
| Functional Test | | Functional Test |
| =============== | | =============== |
| | |
| Bugs | | Bugs |
| ==== | | ==== |
| When a bug is discovered, here is the procedure to follow: | | When a bug is discovered, here is the procedure to follow: |
| 1) write a testcase reproducing it (either in test/bugtrack either in | | 1) write a testcase reproducing it (either in test/bugtrack or in |
| test/unrelated, depending upon the bug being reported on sf or not) | | test/unrelated, depending upon the bug being reported on sf or not) |
| 2) if the bug was not reported on sourceforge, provide enough information in | | 2) if the bug was not reported on sourceforge, provide enough information in |
| testcase comments to describe the bug, preferrably at the top of test | | testcase comments to describe the bug, preferrably at the top of test |
| file, after the GPL licence header. | | file, after the GPL licence header. |
| 3) when you successfully wrote a failing testcase demonstrating the bug, start | | 3) when you successfully wrote a failing testcase demonstrating the bug, start |
| to fix it (by writting the test you probably got a good idea of what goes | | to fix it (by writing the test you probably got a good idea of what goes |
| wrong and the automated test will test each fix attempt for you) | | wrong and the automated test will test each fix attempt for you) |
| 4) provide short information in test source code on what was wrong. If a later | | 4) provide short information in test source code on what was wrong. If a later |
| change in crossfire revive the bug, it will help fix it quickly. | | change in crossfire revive the bug, it will help fix it quickly. |
| | |
| explicitly. Do not name it things like test-map or alike. Prefer forms like | | explicitly. Do not name it things like test-map or alike. Prefer forms like |
| rsc/maps/walls_blocks_move or like rsc/arch/selection_of_magic_books | | rsc/maps/walls_blocks_move or like rsc/arch/selection_of_magic_books |
| each file in src/* should be documented in rsc/index.txt so other coders can | | each file in src/* should be documented in rsc/index.txt so other coders can |
| reuse those resources. each subdirectory of rsc should have it's own index file. | | reuse those resources. Each subdirectory of rsc should have its own index file. |
| | | |
| Toolkits | | Toolkits |
| ======== | | ======== |
| For some testcases (specially the functionnal one), you may need to have a | | For some testcases (especially the functionnal one), you may need to have a |
| specific crossfire configuration loaded, or to do specific map operation. It | | specific crossfire configuration loaded, or to do specific map operation. It |
| won't be surprising some of those operation are generic enough to be shared | | won't be surprising some of those operation are generic enough to be shared |
| amongst all testcases. such support function (aka toolkits) will be made | | amongst all testcases. Such support function (aka toolkits) will be made |
| available in the toolkit directory. | | available in the toolkit directory. |
| | | |
| Includes | | Includes |