The CamiTK Automatic Test framework¶
Since: CamiTK 4.1
or how to easily add integration test to your extension
Testing can be a time consuming task, this is why CamiTK comes with automatic tests tools directly implemented in the CamiTK framework. Every action and component extensions of the CamiTK opensource framework and of any other CEP can be automatically tested thanks to the CamiTK testing framework.
It is very simple to set up a testing environment for the development of your extension, this page details the different steps and possibilities.
CamiTK automatic test framework overview¶
Based on the common API for
Action extension, the CamiTK testing framework can automatically test some aspects of any extension.
You can refer to the technical overview whitepaper about testing in CamiTK to learn how testing is done in the CamiTK framework and in CamiTK Community Edition.
For each component extension, the test procedure has three possible level from level 1 (basic testing) to level 3 (most advanced testing so far). By default the component extension is tested at level 3. If for some (good) reason you don't want to run the test at level 3, you can downgrade the level to level 2 or level 1.
Testing a component extension requires some data. The files to test are expected to be in the
testdata subdirectory of a component extension.
This level performs two steps:
- Load the component extension
- Open a file
It checks that the component extension can be loaded by a CamiTK application and that a test file can be opened.
Level 2 is the same as level 1, but it adds an extra step:
- Save the loaded component to another file
It checks that the component can be saved. This level can only be run if the component extension implements the
Level 3 is the same as level 2, but it adds one other extra step:
- Make a diff between the input file and the output file.
It checks that the input and output data are exactly the same.
For each action in the action extension, the action is tested using a test file. Basically the test consists in calling the
apply() method of the action on the loaded component. The test pass if the
apply() method returns
ABORTED and fails otherwise.
when test is
ABORTED, you need to make sure that this is what you expected.
if the action cannot be applied to this type of component, the test pass. This is a limitation of this CamiTK test module.
apply() method is tested with default parameters defined in the action itself (unit testing). This is up to the action developer to configure its testing procedure with correct default values.
Testing an action extension requires some data. The files to test are expected to be in the
testdata build directory (i.e., the files used to tests action should be present in one of the
testdata directory of one of the component extensions).
At the time of writing, there is only one level of test for actions, it consists in the following steps:
- Load all the component extensions
- Open a test file (should be found in one of the component extensions
- Run the action on the instantiated component
- Check the action status
Pipelined integration tests¶
Since CamiTK 4.1, you can also define a pipeline of actions to perform using the automatic integration test framework.
In this case, the CamiTK action state machine application is used to perform the actions defined in your pipeline one after the other automatically. Any file saved during the pipeline execution is going to be compared to the expected file and the test fails if any of the output files differ from the expected output files.
For instance, you can define a pipeline to:
- open an medical image from
- perform one filter
- save the result to
- perform a mesh 3D reconstruction
- save the result to
When the test is executed all these actions are performed automatically one after the other and the resulting
output-2.vtk are compared to expected files.
The test succeed if the output files are equals to the expected output files.
You can record a first version of your pipeline using the "Save History" feature of
camitk-imp. You will have to edit the resulting SCXML file in order to format the names of the input and output files. The SCXML, input and output files should be placed in a
integration-test subfolder of either your component or action extension.
The main limitation for this automatic test is of course that you cannot use actions that requires user interaction (but he! of course, this is automatic tests, so there is no user to interact with the test...).
Step-by-step: How to automatically test your extension¶
You can easily add one or all of the following tests to your extension:
- automatic test of your extension (as described at step #2)
- additional test for existing actions that are already installed (as described at step #3)
- pipelined integration tests (as described at step #4)
Tests are made in your own CEP context and do not take into account a possible installation. For instance, if you decide to proceed with the installation of your CEP components in CamiTK. It will be loaded with all other CamiTK component. This will lead you to an error message and a fail for your test.
Step 1: Enable the CamiTK testing framework¶
The first thing to do is to tell CMake that for this project you want to enable your test. In the top level
CMakeLists.txt of your project (if you're working on a CamiTK Extenstion Project, open the top level
CMakeLists.txt file and add the option
ENABLE_TESTING to the
1 2 3
camitk_extension_project(... ENABLE_TESTING )
Step 2: Enable automatic test of your extension¶
CMakeLists.txt of your component or action extension, add the
ENABLE_AUTO_TEST option to automatically let the CamiTK test framework create some test. Tests will be automatically generated for your extension.
1 2 3 4 5 6
camitk_extension(COMPONENT_EXTENSION CEP_NAME MYCEP DESCRIPTION "my extension description" ENABLE_AUTO_TEST [TEST_FILES file1 file2...] [AUTO_TEST_LEVEL level] # only for component extension
As you can see above, there are two other option you can set to match specific requirements for your test:
AUTO_TEST_LEVELoption (for component extension)
TEST_FILES let you specify the list of files to use for testing. If provided, only the filenames are required (not the absolute paths), each of them should be found in the
testdata build dir. If no test files are provided then:
- For component extension: all the files in the component
testdatasubdirectory are used by default
- For action extension: all the files available in the
testdatabuild dir (i.e., all the test files found in all the component
testdatasubdirectories) are used by default (note that it might be a lot of files!).
Specific case if you do not have any component in your CEP or if your component extensions do no provide any test files, you need to ensure that the test files used uniquely for testing your action are present in the
testdata directory of the build directory. The
testdata directory is in the subfolder
share/camitk-x.y of the build directory (where
x.y is the major.minor version of CamiTK)
For component extension, the parameter
AUTO_TEST_LEVEL let you specify the level of automatic test to perform (if not specified, the default is 3, see also above):
- Level 1: load the component extension, open and close a test component file
- Level 2: same as level 1, but save the component before closing it.
- Level 3 (default): same as level 2, but also compare the saved component to the input.
Step 3: Define additional test for existing actions¶
In some cases, it can be useful to test your component with actions that are already installed (e.g., with an action provided by the CamiTK Community Edition).
For instance: if you develop a new component extension that derived from
ImageComponent, an additional test can be automatically generated by the CamiTK test framework in order to check that the existing ITK Otsu filter action (provided by the CamiTK Community Edition) works on your new component.
camitk_additional_action_test is here to do just that: it creates an additional level 1 test for an existing (installed) CamiTK action using test data from the current component extension.
This macro can be used to check the quality of the integration level of a new component extension defined within a CEP introduces. It will take new test files and run the defined action.
If the new component class derives from an existing (installed) component class for which there are existing (installed) actions, these actions should indeed works using the new derived component class.
For example: if a CEP introduces a new
MeshComponent derived class, then all the actions that works on
MeshComponent should also work on the new component.
To define an additional test for an existing action, you only need to modify the component extension
CMakeLists.txt, and add one line just after the
camitk_extension(COMPONENT_EXTENSION ...) macro, at the end of the
1 2 3 4
camitk_additional_action_test(ACTION_EXTENSIONS action1 action2 ... [TEST_FILES file1 file2 ...] [TEST_SUFFIX name] )
ACTION_EXTENSIONSis the list of the action extension that will also be tested with the given test files. Only the action extension name (not the full library/dll name nor the path) should be provided. This macro checks the existence of the extension library/dll in the following directories (in this order): build dir; user install dir and global install dir. The first action that is found is used for the tests.
TEST_FILESis an optional argument. It can specify the list of files to use for testing. If not set, then all the files in the
testdatasubdirectories are used. If provided, only the filenames are required (not the absolute paths) and all the given files should be in the
testdatasubdirectory of the current component.
TEST_SUFFIXis an optional argument. It provides the suffix name for the additional test. Default value is the name of the current component extension. The resulting test will be called
Ais the action name,
Cthe component name and
ithe test order number depending of the filename order).
Step 4: Add pipelined integration tests¶
To add a test that will run a pipeline of actions, apply them and check the result against resulting output, you just need to:
- create a
integration-testdirectory in your component or action extension source directory
- add the
ENABLE_INTEGRATION_TESToption to the
1 2 3 4
camitk_extension(... ... ENABLE_INTEGRATION_TEST )
- create a
asm-input.xmlSCXML document that describes the action pipeline. To create a SCXML file, the best way to start is to run
camitk-imp, select, set the parameters and apply the actions you want to perform in your test (do not forget to use the
Saveaction to output some or all of the resulting component). Then go to the
Filemenu and choose
Save History. You will then have to manually edit the resulting XML file in order to fullfil the requirements (see below)
- rename all the input files needed to run your pipeline to the normalized form
input-#.xxxand copy them to the
- rename all the expected output files to compare with actual output to the normalized form
output-#.xxxand copy them to the
- run the CMake configuration again, et voilà, a new test called
extensiontype-integration-testshould be available
You can find an example in the
itkfilters action extension of the
imaging CEP (provided in the CamiTK Community Edition), and in the
image/reconstruction action extension of the SDK.
In order to transform a saved history to an functional
asm-input.xml, you will need to edit the XML files with an XML aware editor. Just follow the step-by-step below.
Here are the steps required to transform a saved history SCXML to an functional
- Move all your input files to the
integration-testdatasubdirectory and rename them using the normalized form
#is the unique index
- Move the
- Change (if any)
Open Fileinstead (
Open Filedoes not require user interaction or the use of an open dialog):
1 2 3 4 5
... <camitk:action> <camitk:name>Open</camitk:name> <camitk:parameters/> ...
1 2 3 4 5 6
<camitk:action> <camitk:name>Open File</camitk:name> <camitk:parameters> <camitk:parameter name="File Name" value="input-#.mha" type="QString"/> </camitk:parameters> ...
- For each action that produce a new component that will be later saved and compared to the expected result, you need to rename the component output name throughout the SCXML document to the normalized form
#is a unique index and
xxxis the proper extension to save. For instance:
1 2 3 4 5 6 7 8 9 10 11 12
<camitk:action> <camitk:name>An Action That Creates a New Component</camitk:name> <camitk:parameters> ... </camitk:parameters> <camitk:inputs> ... </camitk:inputs> <camitk:outputs> <camitk:component name="named created automatically by the action (sometimes without extension)" type="ComponentClass"/> </camitk:outputs> ...
1 2 3 4 5 6 7 8 9 10 11 12
<camitk:action> <camitk:name>An Action That Creates a New Component</camitk:name> <camitk:parameters> ... </camitk:parameters> <camitk:inputs> ... </camitk:inputs> <camitk:outputs> <camitk:component name="output-#.xxx" type="ComponentClass"/> </camitk:outputs> ...
- Change (if any)
Save Asaction into
Saveinstead. Also make sure that the input parameter of the
Saveaction is using a component name corresponding to one of the
output-#.xxxthat you renamed in the previous step.
- You may also rename the state's
idattributes in order to use more explicit names (do not forget to modify the corresponding transition's
- test the
asm-input.xmlusing the action state machine:
1 2 3 4 5 6 7
# On the command line, go to the directory where you stored all input files and asm-input.xml documents camitk-actionstatemachine --file asm-input.xml --output-dir . # you should only have to press "Next" # The execution ends up with all the expected output in a new YYYY-MM-DDTHH-MM-SS directory # There should be no diff between the expected output and the actual output (sometimes you need to run it once to produce the proper expected output) # if that works well try the autonext option (it should not just run without any user interaction) camitk-actionstatemachine --file asm-input.xml --output-dir . --autonext
Step 5: Run your tests¶
Run all the tests¶
CMake automatically creates a target to run all the tests you have configured, that include the automatic test generated by the CamiTK testing framework.
- On Linux and MacOS the target's name is test so simply run:
- On Windows system, running a Visual Studio instance, simply build the project
Run specific tests¶
It is possible to have a finer control on running the tests.
Your build directory must contain a file named
CTestTestfile.cmake (generated during the configuration stage). This will allow you to type the following command, to execute some of the tests defined:
ctest -C <configuration> -V # note that "-C <configuration>" is optional on Linux and MacOS
ctest -C Debug -V # note that "-C Debug" is optional on Linux and MacOS
-V option is for verbose,
-VV is for extra verbose
For a specific test identified by its index use the
ctest -C debug -I <start index>,<end index>
ctest -C debug -I 5,8 # this will execute test #5, #6, #7 and #8
For a specific test identified by its name, use the
ctest -VV -R <test-name-regex>
ctest -VV -R action-myactionname # this will execute all the tests automatically created for myactionname
The CamiTK test framework add specific prefix to the tests it automatically creates:
action-xxx → prefix of all the tests defined for the action extension named
component-xxx → prefix of all the tests defined for the component extension named
application-xxx → prefix of all the tests defined for the application extension named
Step 6: Check test coverage of your CEP¶
A report on test coverage can also be generated automatically for any CamiTK Extension Project. The requirements are that:
- you need to use the GNU cxx compiler
- you need to have gcov and lcov installed (apt-get install is your friend !)
Then, it is very easy: open the top level
CMakeLists.txt file of your CamiTK
Extenstion Project and add the option
ENABLE_TEST_COVERAGE to the
1 2 3
camitk_extension_project(... ENABLE_TEST_COVERAGE )
Once your project is built, you can then run the
It will run all the available tests of your CEP using
ctest and then compute the test coverage and generat an html report. The reports will be available for visualisation in
camitk-test-coverage subdirectory of the build dir).
So for instance, just type:
Step 7: Add continuous integration¶
If your project is hosted on a gitlab server, you can quickly add continuous integration (CI) so that each modification triggers a configure/build/test pipeline. CI is very useful for mature code to set high level of code quality in order to protect your code from any regression.
In order to do that you need:
- to install gitlab runners (they are in charge of executing the pipeline on the VM/OS of your choice)
- to add a specific
.gitlab-ci.ymlconfiguration file in the root directory of your CEP.
CamiTK Community Edition has continuous integration in place, so that:
- each push to the gitlab hosted code (in any branch) triggers the CI pipeline
- each day a nightly pipeline is executed on the
CamiTK Community Edition uses 4 different runners: three on Linux (debian stable, old stable, and Ubuntu LTS, all using a docker executor) and one on Windows (Win7 using a bash shell executor).
In the end we get a summary of all the results (as well as report artefacts and emails to the developer in case of an error) send to the CamiTK Community Edition dashboard. For instance, this shows where a the nightly build:
Contact us if you would like more information about this and some support and help on how to set CI in place powerful for your project.