diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox index 9db8cd4b69..bda97667b8 100644 --- a/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox +++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox @@ -1,72 +1,72 @@ /** \page GeneralTests General: Tests in MITK \tableofcontents \section GeneralTestsIntroduction Testing in MITK The basic idea about unit testing is to write a test for every class (unit) of your software. The test should then run all methods of the tested class and check if the results are correct. MITK uses CppUnit, which provides a framework for efficient and fast test writing. The following sections will explain how to write your own tests with MITK and how to run them. A specific type of unit test are rendering tests. These are explained in more detail in the section \ref RenderingTests. \section GeneralTestsAdding Adding a test to your module Generally code you want to test using unit tests will be located in a module. For an overview of the directory structure see \ref NewModulePageCreateFolder and how to add the files comprising your test compare \ref NewModulePageCreateTestingEnvironment \subsection GeneralTestsAddingFramework The testing framework In order to create a test you need to create a new class deriving from mitk::TestFixture. While a purist approach would be to create a new mitk::TestFixture for each method of your class (resulting in as many test source files as your class has methods), we usually follow a more pragmatic approach within MITK. In most cases we suggest having one test source file per class. If your class source file is called mitkGreatClass.cpp we suggest the name mitkGreatClassTest.cpp for your test source file. For very complex and long classes splitting this into several tests may be advisable. In order to use CppUnit via MITK you will need to include the corresponding files and register your test: \code #include #include … MITK_TEST_SUITE_REGISTRATION(mitkImageEqual) \endcode \subsection GeneralTestsAddingHow How to structure your test You should derive from mitk::TestFixture. A suggested name for your test class would be TestSuite. You then create a suite and register your test methods. A suggested naming convention for test methods is __ An example: \code class mitkImageEqualTestSuite : public mitk::TestFixture { CPPUNIT_TEST_SUITE(mitkImageEqualTestSuite); MITK_TEST(Equal_CloneAndOriginal_ReturnsTrue); MITK_TEST(Equal_InputIsNull_ReturnsFalse); MITK_TEST(Equal_DifferentImageGeometry_ReturnsFalse); MITK_TEST(Equal_DifferentPixelTypes_ReturnsFalse); … CPPUNIT_TEST_SUITE_END(); … } \endcode You also need to provide a setUp() and a tearDown() function. These will be called before/after each test and should be used to make sure that each test method works independently and on freshly initialized members. That way you avoid only testing whether a function works after another function has already been called. For an example test see \ref GeneralTestsExample \section GeneralTestsRunning Running your test The build system of MITK generates a test driver which includes all tests that have been added to the project. Alternatively you can run MITK tests by using the program ctest. This is the way all MITK tests run on the continuous dart clients of MITK. The results of these runs can be found at http://cdash.mitk.org. If you use the test driver, you only need to start the executable. If you start it without parameters, it will then give you an overview of all tests which are included in this test driver and you can choose one by typing a number. \note This way you can not set additional input, such as images. Alternatively you can give your test driver the name of your test as parameter. Then this test will be started directly. You are also allowed to give more parameters which are then given to the main test method as parameters (argv[]). If you want to use ctest instead of the test driver you need to start a command line, go to the binary directory of MITK and call ctest. To avoid errors, check if your path variable contains all relevant paths to start MITK. \section GeneralTestsExample An example -\include Examples\FirstSteps\NewModule\test\mitkExampleDataStructureTest.cpp +\include Examples/FirstSteps/NewModule/test/mitkExampleDataStructureTest.cpp \section GeneralTestsFurtherInfo Further information More examples can be found in the corresponding bugsquashing presentation. */ diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewModule.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewModule.dox index b34961f929..609cdd831d 100644 --- a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewModule.dox +++ b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewModule.dox @@ -1,122 +1,122 @@ /** \page NewModulePage How to create a new MITK Module \section NewModulePageCreateFolder Create a Folder for your Module First, create a folder for your module within /Modules e.g. 'NewModule'. You need to add the new Folder to the CMakeLists.txt in the Module directory as well as well. Open /Modules/CMakeLists.txt, insert it into the set(module_dirs) section. \code set(module_dirs ... NewModule ) \endcode A simple example module is provided in the MITK/Examples/FirstSteps/NewModule directory, it includes a new data type (more information at \ref NewDataTypePage) and adds a MiniApp for that data type (more information at \ref MiniAppCommandLineToolHowToPage). Within the module we recommend using a Unix like directory structure. This helps others finding their way around your code. Depending on your use case you might not need every directory. \code NewModule/ autoload/ cmdapps/ doc/ include/ resource/ src/ test/ \endcode Subsequently a quick description of what each directory contains. \subsection NewModulePageCreateFolderAutoload autoload This directory should not directly contain files. Instead it contains further directories each of which is its own module. These modules provide functionality which should be available at application start, but will not be included by other modules. Examples would be a module registering readers/writers or providing an interface for specific hardware. For an example of an autoload module take a look at NewModule/autoload/IO. \subsection NewModulePageCreateFolderCmdApps cmdapps This directory contains all cmdapps (command line tools) related to your module. For more information see \ref MiniAppCommandLineToolHowToPage. \subsection NewModulePageCreateFolderDoc doc This directory contains the documentation for your module. \subsection NewModulePageCreateFolderInclude include This directory contains all header files which might be included by other modules. \subsection NewModulePageCreateFolderResource resource This directory contains resources needed by your module, such as xmls, images or similar. \subsection NewModulePageCreateFolderSrc src This directory contains source and header files which should not be included by other modules. Further subdivision can help keeping it organized. (e.g. src/DataManagement src/Algorithms) \subsection NewModulePageCreateFolderTest test This directory contains all tests for your module. \section NewModulePageCreateCMakeLists Create CMakeLists.txt Within your module create a CMakeLists.txt using the MITK_CREATE_MODULE macro: An example: -\include Examples\FirstSteps\NewModule\CMakeLists.txt +\include Examples/FirstSteps/NewModule/CMakeLists.txt If you do not choose a module name, one will be generated based on the folder name (In this case the resulting name will be MitkNewModule). This name has to be unique across the entire project in order to avoid collisions. It should only contain Letters (both upper- and lowercase), no numbers, no underscores etc. An example of an autoload module that sets its own name is: -\include Examples\FirstSteps\NewModule\autoload\IO\CMakeLists.txt +\include Examples/FirstSteps/NewModule/autoload/IO/CMakeLists.txt the resulting name is MitkNewModuleIO. \note For more information about the parameters of the new module macro see mitkFunctionCreateModule.cmake \section NewModulePageCreatefilesdotcmake Create files.cmake Next, create a new file and name it files.cmake, containing the files of your module. An example: -\include Examples\FirstSteps\NewModule\autoload\IO\files.cmake +\include Examples/FirstSteps/NewModule/autoload/IO/files.cmake If you do not add a source file here it will not be compiled, unless it is included elsewhere. \section NewModulePageCreateTestingEnvironment Set up the Test environment Providing tests for your code is a very good way to save yourself a lot of debugging time and ensure consistency. An example of a small test environment is provided in the NewModule example. Again you need a CMakeLists.txt, e.g.: -\include Examples\FirstSteps\NewModule\test\CMakeLists.txt +\include Examples/FirstSteps/NewModule/test/CMakeLists.txt a files.cmake, e.g.: -\include Examples\FirstSteps\NewModule\test\files.cmake +\include Examples/FirstSteps/NewModule/test/files.cmake and an actual test, e.g.: -\include Examples\FirstSteps\NewModule\test\mitkExampleDataStructureTest.cpp +\include Examples/FirstSteps/NewModule/test/mitkExampleDataStructureTest.cpp For more information regarding tests please refer to \ref AboutTestingPage. That's it! Enjoy your new module! */ \ No newline at end of file