Difference between revisions of "Tutorial Writing Unit Tests for Bundles"

From mitk.org
Jump to navigation Jump to search
m
 
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
 
'''Preliminary version!!''' This tutorial will be extended in the future. Below you can find a short summary about the concepts:
 
'''Preliminary version!!''' This tutorial will be extended in the future. Below you can find a short summary about the concepts:
  

Latest revision as of 16:01, 4 December 2014

Preliminary version!! This tutorial will be extended in the future. Below you can find a short summary about the concepts:

Unit tests for a specific bundle, for example my.domain.bundle, should be placed in their own bundle, preferably named my.domain.bundle.tests (it is possible to put the tests right inside the my.domain.bundle, though).

Test classes inherit from berry::TestCase (subclass of CppUnit::TestCase from Poco) or from berry::!UITestCase if they need a running workbench. They can be combined into test suites. A test (or suite) is "registered" via the org.blueberry.tests extension point.

If you enable BLUEBERRY_DEBUG_SMARTPOINTER in your CMake configuration, tests will only succeed if there are no dangling berry::Object instances.

The "testdriver" is a OSGi application contained in the bundle org.blueberry.test. The application can be started as any other application by supplying --BlueBerry.application=coretestapplication as command line argument to a BlueBerry executable. In order to run UI tests use the uitestapplication application in the org.blueberry.uitest bundle.

All tests are run inside the OSGi framework and as such the code to be tested can be executed in its "native environment".

Look at the org.blueberry.osgi.tests and org.blueberry.ui.tests bundles for example implementations of UI and non-UI unit tests.