Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tests for the CaPTkExample module #100

Open
dboun opened this issue Feb 26, 2020 · 5 comments
Open

Add tests for the CaPTkExample module #100

dboun opened this issue Feb 26, 2020 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@dboun
Copy link
Collaborator

dboun commented Feb 26, 2020

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 dboun added the enhancement New feature or request label Feb 26, 2020
@dboun
Copy link
Collaborator Author

dboun commented Feb 27, 2020

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
Copy link
Collaborator Author

dboun commented Feb 27, 2020

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
Copy link
Collaborator

@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
Copy link
Collaborator

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

@dboun
Copy link
Collaborator Author

dboun commented Feb 29, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants