Heiko Klare edited this page May 23, 2018 · 8 revisions

Table of Contents


On this page, we will collect information about how to test the Vitruv framework and applications for it.


For testing applications, the VitruviusApplicationTest base class is provided. It requires the specification of four methods:

  1. getVitruvDomains: Returns the domains that are relevant for the application test
  2. createChangePropagationSpecifications: Returns the ChangePropagationSpecifications developed for the applications, e.g., using the Reactions language
  3. setup: Is automatically called before each test case. It is intended to initialize the test source model. It can be used to initialize a common test model for all tests so that is must not be implemented for each test case.
  4. cleanup: Is automatically called after each test case. Can be used for cleanup operations or be left blank if not needed.
If provides several methods that can be used in tests, especially:
  1. createAndSynchronizeModel: Creates a model with a given root element and a given path, propagates the model creation change and starts recording further changes
  2. saveAndSynchronizeChanges: Saves the model of the given element and propagates all changes performed within that model since last change propagation
  3. For further utility methods see the class documentation.

Test runtime projects

For each test case, two projects get created: one for the project itself and one for the VSUM information. By default, these projects are placed in a temporary folder. To specify a specific folder in which the test projects shall be stored, the VM argument testWorkspacePath can be set. For examples, specifying -DtestWorkspacePath=TEST would place the projects in the folder with the absolute system path TEST.

Debug Output

For debug outputs, we use the Apache Log4j logger. Within a Reactions specifications, a logger can be addressed as logger in each code block.

The granularity of the debug output can be specified for a logger by calling the setLevel(Level) method on it. When using a VitruviusChangePropagationTest, the logger is automatically managed. The debug level can be specified by defining the VM argument logOutputLevel. For example, specifying the parameter -DlogOutputLevel=DEBUG as a VM argument, the logger will output any logging information that is on debug level or above (warning, error etc.).

Technical Hints

Running Application Tests

Running Vitruv tests, which especially means running tests in classes derived from VitruviusApplicationTest, have to be executed as JUnit Plug-in tests (not as ordinary JUnit tests). This is due to the reason that those tests start an instance of the Vitruv framework and thus depend on an Eclipse/EMF instance.

The Run Configuration of such a test should be modified afterwards to improve performance. The goal of this modification is to reuse the workspace configuration of previous test runs instead of always creating a new configuration (as this requires much time). To do so, open the Run Configuration, go to Configuration and disable under Configuration Area the checkbox Clear the configuration area before launching.

Maven Tycho

The tycho-surefire-plugin for Maven executes JUnit Plug-in tests in the tests folder if they are appropriately named (e.g. ending with "Test"). If you have ordinary JUnit tests that cannot be executed as Plug-in tests, you have to add some specification to the pom.xml of the specific project to make Maven use the maven-surefire-plugin instead of the tycho-surefire-plugin:

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.