-
Notifications
You must be signed in to change notification settings - Fork 37
How to Create a Simple Test Case
This page is to walk you through the things you have to do to make a test case. WE assume that you have a DMN model, and that model is available in XML form. While the model may be very big and complex, there are only a few things you need to know to make a test. Below is a DMN model for example:
<?xml version="1.0" encoding="UTF-8"?>
<definitions id="_0001-input-data-string" name="0001-input-data-string"
namespace="https://github.com/agilepro/dmn-tck"
xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd"
xmlns:feel="http://www.omg.org/spec/FEEL/20140401">
<decision name="Greeting Message" id="d_GreetingMessage">
<variable name="Greeting Message" typeRef="feel:string"/>
<informationRequirement>
<requiredInput href="#i_FullName"/>
</informationRequirement>
<literalExpression>
<text>"Hello " + Full Name</text>
</literalExpression>
</decision>
<inputData name="Full Name" id="i_FullName">
<variable name="Full Name" typeRef="feel:string"/>
</inputData>
</definitions>
This is a very simple DMN with a single input and a single output. The input is named "Full Name" and the output is named "Greeting Message". The entire thing is saved in a file called "0001-input-data-string.dmn".
Below is a template of a test case with tokens in the places to be filled in.
<?xml version="1.0" encoding="UTF-8"?>
<testCases xmlns="http://www.omg.org/spec/DMN/20160719/testcase"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<modelName>{1}</modelName>
<labels>
<label>{2}</label>
<label>{2}</label>
</labels>
<testCase id="{3}">
<description>{4}</description>
<inputNode name="{5}">
<value xsi:type="{6}">{7}</value>
</inputNode>
<resultNode name="{8}" type="decision">
<expected>
<value>{9}</value>
</expected>
</resultNode>
</testCase>
</testCases>
Generally tests will employ names that repeat each other. This is not required. The test case file specifies any number of separate test cases. The entire set of tests might be called a test set. Pick a good name for the test set. This name starts with a unique test set number (to simply references to it) and then some explanation text using hyphens between the words.
There is currently an agreement that the number range from 1000..2000 is reserved for auto generated test cases of by ACTICO DMN Runtime (ref: https://github.com/dmn-tck/tck/pull/204#issuecomment-445715352), so leaving reserved that number range for ACTICO contributions it is advised to pick the next set number available; or alternatively ask to reserve a new range if planning to submit several auto generated test cases.
In this example, the test set is named "0001-input-data-string".
Create a folder with the name of the test set: "0001-input-data-string".
The test file has the same name of the test set with a "-test-99.xml" suffix, where 99 is replaced by an incremental counter. Thus for this case we might name the file "0001-input-data-string-test-01.xml"
The DMN file also by convention has the same name as the test set as well. Thus the DMN file would be named "0001-input-data-string.dmn" It is not required to have this name, because the test file actually specifies the exact name of the DMN file, but it is a convention used by the test runners to execute the tests.
You might have some other files in the folder, but these are expected to be supporting documentation. Often a PDF files is included that shows the DMN diagram, but that is not required. These are ignored as far as the testing is concerned.
In the spot marked {1} above, put the entire name of the DMN file, exactly as it appears in the folder.
You can specify as many labels as you want. Please check with the Glossary to get suggestions for the labels to use. The labels are used to group certain results together, and to help people to find tests that they might be interested in, but they don't effect the running of the tests in any way.
Within the test file, each test case must have a unique ID. The actual id values does not matter, only that it is unique. The first test case in the file is generally numbered "001" and each one following has an incremental number. The id can also be non numeric.
The "testCase" tag surrounds all of the elements of an individual test. Each test case runs independently of anything else in the file. TestCases must be designed so they can be run individually, as part of a longer running process, and the cases might be run in any order. Each test case will be completed before trying to run another test case.
Be descriptive in order to let people know that the purpose of the test cases is, what it is trying to test. This information is reflected to the web site where it will be the only description of the test case, and at that location there input and output values are not visible, so be as succinct and complete and possible. The description does not effect the running of the tests in any way.
This example has only one input, but in general a test may have any number of input values. Each input value must be associated with a name of an input to the DMN model, specified by an "inputData" tag or a "decision" tag in the model. In this example, the only input value is named "Full Name" and so the input node must also be named "Full Name".
The value tag exists within the input node tag to contain the value that will be set into that name and given to the model. You may optionally specify the type. The runners look at the data and attempt to determine the type from the form of the data or by inspecting the model. For example, the value "1006" contains only numerals and might be assumed to be a number in some runners or a type as defined in the model for others. If you want to ensure no ambiguity and for the input to be treated explicitly as a given type, like a string for instance, then you will need to specify the type in order to override what the runner would normally assume.
This is where you specify the actual value that will be associated with that input name.
The dmn model will produce a result. It may produce multiple results, and each result has a name. A given decision (defined by decision tags) will have a name, and there is also a variable (defined by a variable tag) which has the same name. That name used in both of these places is the name of the output.
This is where you place the actual value that will be used to compare with the output of the model. IF the values are the same, then the test passes. If not, it fails.