Add tests for the CaPTkExample module

[dboun]

This can serve as a first step towards integrating tests, as we will get to explore how it can be done correctly.

THIS HAS TO BE DONE AFTER FEATURE #36 (Add sample data for tests)

In particular we want to test captk::ExampleAlgorithm (in Modules/CaPTkExample/include/CaPTkExampleAlgorithm.h). Example usage can be found in [Modules/CaPTkExample/cmdapps/CaPTkExampleCmdApp.cpp:128]

Testing here means:

• Have 1 image and 1 expected output
• Run algorithm using the 1 image
• Check if the output we get is identical to the expected output

[dboun]

Please note that the requirement of feature #36 is now (hopefully) satisfied by PR #103.

I think the idea is to #include <CaPTkData.h> in the tests and then use the following variables to get to the root of the data dir:

std::vector< std::string > captk::data::relative_search_dirs;
std::vector< std::string > captk::data::absolute_search_dirs;

If these paths don't end up working, we will have to tweak them in the [code], especially the absolute one

[dboun]

If you look at [MITK-Diffusion] ---> Modules/FiberTracking/Testing there is testing done. An introduction:

Simple tests

In the CMakeLists, notice "calls" like:

mitkAddCustomModuleTest(
  mitkFiberTransformationTest 
  mitkFiberTransformationTest 
  ${MITK_DATA_DIR}/DiffusionImaging/fiberBundleX.fib 
  ${MITK_DATA_DIR}/DiffusionImaging/fiberBundleX_transformed.fib
)

First argument is the test name, second is which function to invoke for this test. Following that are arguments to be passed to the test, 2 in particular. Both files are in ${MITK_DATA_DIR}. For us that would be ${CaPTkData_DIR} as per PR #103.

For these simple tests, there is no need for CaPTkData.h stuff.

Complex, but generally conventional, tests

Look at mitkMachineLearningTrackingTest.cpp. It extends mitk::TestFixture which is part of the MITK Core module. This is basically a class and will find the data from CaPTkData.h (I think), so there is no data argument in cmake like before. The corresponding line for the complex test writes:

mitkAddCustomModuleTest(
  mitkMachineLearningTrackingTest
  mitkMachineLearningTrackingTest
)

[ashishsingh18]

@dboun They are generally following the unit testing pattern from ITK and VTK. However, keep in mind that all these folks, generally write tests for a class(as a unit). Their classes are designed in such a a way that each class has a single responsibility that can be easily tested. We will need to follow a similar structure which is a good practice and easy to understand and maintain as well.

If you look through their code, they have tests for pretty much each module. As an example see the image denoising test

[ashishsingh18]

some more info about this:
http://docs.mitk.org/nightly/GeneralTests.html

[dboun]

@dboun They are generally following the unit testing pattern from ITK and VTK. However, keep in mind that all these folks, generally write tests for a class(as a unit). Their classes are designed in such a a way that each class has a single responsibility that can be easily tested. We will need to follow a similar structure which is a good practice and easy to understand and maintain as well.

Yes!

If you look through their code, they have tests for pretty much each module. As an example see the image denoising test

This example you linked from denoising is not what we want, though. It is a very archaic way to do testing, they basically run it and judge if it returns exit failure (I think?)

If you look elsewhere they use mitk::TestFixture etc. I think this is based on CppUnit and is on par with what you linked from the docs. Although for the core of the algorithms it might not be a bad idea to do tests relying on CppUnit and not on mitk's cust way, for better transferability. But that's a topic to discuss in person.