Difference between revisions of "Slicer-3.6-QA"
Line 22: | Line 22: | ||
The '''data processing''' section can be tested by using standard CTest/CMake mechanisms. Basically by adding ADD_TEST() entries to the CMakeLists.txt file of the module. | The '''data processing''' section can be tested by using standard CTest/CMake mechanisms. Basically by adding ADD_TEST() entries to the CMakeLists.txt file of the module. | ||
− | |||
=Luis Ibanez' scoring system= | =Luis Ibanez' scoring system= |
Revision as of 14:52, 15 April 2010
Home < Slicer-3.6-QAReturn to Slicer 3.6 documentation
- This page contains our assessment of the Slicer 3.6 modules and extensions
- See also the module culling event at the end of April 2010
Score | Name | Documentation | Help [1] | Acknowledgment [2] | Test coverage [3] | valgrind errors |
---|---|---|---|---|---|---|
Gold | my module | complete | yes and yes | yes, yes, yes | 80% | 0 |
Testing Partition
Most Slicer modules have a GUI component and a Data Processing component.
Testing GUI components is still a challenge, so we will focus here on testing the Data Processing components. This can be done in most cases by partitioning the module into a GUI section and a Data Processing section, where the second one usually takes the form of a C++ class (although that is not a requirement).
The data processing section can be tested by using standard CTest/CMake mechanisms. Basically by adding ADD_TEST() entries to the CMakeLists.txt file of the module.
Luis Ibanez' scoring system
The following scoring will be applied to the data processing sections of all modules:
Score | Code Coverage | Valgrin Errors | Documentation | Tutorial |
---|---|---|---|---|
Gold | > 80% | 0 | yes | yes |
Silver | > 70% | < 10 | yes | yes |
Bronze | > 60% | < 50 | yes | yes |
Aluminium | > 50% | < 100 | yes | yes |
Coal | > 50% | > 100 | yes | yes |
Plutonium | unknown | unknown | no | no |
The code coverage and Valgrind error must be the ones reported on the Nightly Slicer Dashboard. Anecdotal data is not acceptable.