The purpose of the app.ducx unit test language is to simplify the definition of unit tests.
Using the app.ducx unit test language, you can define the build blocks for unit testing:
A unit test block consists of import declarations and unit test elements. The unittests keyword denotes a unit test block. It must be followed by the reference of your software component and curly braces.
Every file with a .ducx-ut extension can hold exactly one unit test block.
Syntax |
unittests softwarecomponent // Unit test elements (scenarios, unit tests, unit test groups) |
The basic element of the unit test language is the unit test itself. Every unit test can have global variables, an optional setup expression, a test expression and an optional cleanup expression. Additionally, some test contents can be assigned to the unit test.
Syntax |
test reference { init = expression { expression { cleanup = expression { testdata<tdid, tdcontent> = { |
All expressions share the same local scope and can see the global variables of the scenario (see below) and the global variables of the unit test.
When evaluating a unit test, first the scenario is initialized if provided, then the setup expression, the test expression and the cleanup expression are evaluated. The cleanup expression is evaluated regardless of the result of the test expression.
Unit tests can be assigned to unit test groups to evaluate a group of unit tests together.
Syntax |
testgroup UTGAllTests { |
Often different unit tests use the same basic setup. To ensure consistent tests, the init and cleanup code for these tests can be factored out into a so-called scenario.
A scenario consists of some global variables, an expression to initialize the scenario and a cleanup expression.
A unit test can use a scenario to define the setting.
Example |
scenario SCOneUser { expression { cleanup = expression { test UTWithUser using SCOneUser { |
Scenarios can be based on another scenario, thus building a hierarchy of scenarios.
Example |
scenario SCBase { expression { cleanup = expression { scenario SCDetail: SCBase { expression { cleanup = expression { test UTWithBothUsers using SCDetail { |
In production environments the base components for unit testing are not installed. This is taken care of by generating the resulting software component in a way that unit test objects and scenario object are not loaded into such environments.
Note: This mechanism does not take care of component dependencies. All imported components are marked as prerequisites. If a component is used in unit tests and scenarios only, it is recommended to specify this component as optional. The result is a software component that can be loaded, even if some or all of the optional dependencies are not present.
This chapter describes a unit test scenario with all features available to the developer.
Scenario
The app needs two users and a group to test all the functionality, so it is a good idea to create a scenario which is used in all tests.
Example |
scenario SCTwoUsers { init = expression { |
Note: To create users there is a special usecase FSCDUCXUNIT@1.1001:CreateTestUser. This usecase takes some initialization data and creates a valid user in the current environment.
Scenario Hierarchy
To provide even more flexibility, a scenario can be based on another scenario, giving a hierarchy of scenarios.
Example |
scenario SCOneGroupTwoUsers: SCTwoUsers { init = expression { |
Note: To create groups there is a special usecase FSCDUCXUNIT@1.1001:CreateTestGroup. This usecase takes some initialization data and creates a valid group in the current environment.
Unit Tests
All unit tests can use this scenario to create their test environment.
Example |
test UTFolder using SCOneGroupTwoUsers { init = expression { test = expression { |
Note: After executing the test, the created objects need to be deleted, regardless of the success or failure of the test. This can be achieved by registering the new objects to the test session with the use case FSCDUCXUNIT@1.1001:AddToTestSession.
Session Start and Stop
Even in app.test these scenarios can be used to create the environment. All the required data for executing the tests are provided as parameters.
Example |
<Sequence clienttype="External" jarfile="apptest-commander.jar" classname="Commander"> |
To remove the created objects the session can be closed, too.
Example |
<Sequence clienttype="External" jarfile="apptest-commander.jar" classname="Commander"> |