OpenTestSystem.Otx.Extensions.UnitTest Namespace Reference

Ensuring OTX code quality via unit tests More...

Namespaces
namespace	Actions
	Lists all ActionRealisation extensions defined in the UnitTest.
namespace	Declarations
	UnitTest Declarations
namespace	Nodes
	UnitTest Nodes
namespace	Terms
	Lists all Terms defined in the UnitTest.

Classes
class	CheckerRule
	Comprehensive checker rule listing, see also Core checker rules. More...
class	TestProcedures
	Root element of UnitTest extension. More...

Detailed Description

Ensuring OTX code quality via unit tests

With the UnitTest extension, OTX procedures can be tested related to expected behavior using unit tests or integration tests. Unit tests are part of the software development process to ensure the expected behavior of modules, see Introduction into Software Testing. Unit tests are a prerequisite for subsequent integration tests in order to be able to align the test cases with the interaction of larger functional parts or the entire application.

The UnitTest extension extends OTX with a new type of procedure, the so-called test procedure. Several test cases can be assigned to each test procedure. A test cases describe the parameterization of the test and the expected results.

Note

The UnitTest extension complements the Assertion extension.

In order to clearly separate the OTX test logic from its unit tests, all elements of the UnitTest extension cannot be used in normal OTX procedures, but only in test procedures. This restriction does not apply to the Assert action of the Assertion extension.

The UnitTest Extension has no influence on the normal OTX test logic and is stored separately from it.

If a test was executed the test can have the following test results:

Test Result	Description
DISABLED	The test was disabled if the TestProcedure or the TestCase is marked as DISABLED. No subsequent elements will be executed. Use case: For incomplete or wrong test cases or test procedures.
PASSED	The test was passed. The test procedure execution was successful. This will only happens if all expected results of all test cases are fulfilled, all Assert and Assume activities fulfill its condition or a Pass end node was executed.
FAILED	The test execution was failed. This can only happens if an expected result of a test case does not match, an Assert activity does not fulfill its condition or a Fail end node was executed.
IGNORED	The test was ignored. The default result of a test procedure is IGNORED, if this will not explicit changed via a test case or an action or and node or a disabled attribute. A test case can be explicit set to ignored, if the TestCase is marked as IGNORED or a Ignored end node was executed. Conditions: - Corner Case - This should be used if an known problem occurs but only in test conditions, which are not relevant for practical use cases - Wrong Specification - If the test case is right but the specification is wrong - Instable Test Case - The test case will be executed right, if it was executed stand alone, but if it executed inside the entire test suite it can happens sometimes (not every time!) that the test case failed. E.g. this can happens, if the environment is unstable and the problem behind is unknown. Note: A test case wich is marked as IGNORED will be executed, but if it fails, the result is IGNORED and not FAILED. Note: This result has no influence to the overall result of the parent element. Note: An IGNORED test case should contain a understandable message, why it was ignored.
INCONCLUSIVE	The test execution was inconclusive. This can only happens if an Assume activity does not fulfill its condition or a Inconclusive end node was executed. The behavior is similar to FAILED except that an assumption and not a result does not match.

Note: The severity order of the of the result states is DISABLED > FAILED > INCONCLUSIVE > IGNORED > PASSED.