After defining equivalence classes and their representatives we can create test cases. We start with manually adding test cases and editing descriptions of test cases. In the following subsection we will see how to make devmate generate test cases for us. The last subsection will focus on the expected result of test cases. More precisely expected values and exceptions. In general each test case consists of a name, an optional description, a set of representatives and expected results.
Add/Remove a Test Case
We are now going to proceed with our AverageSpeed example and define a couple of test cases.
Add a Test Case at the End
To a test case at the end of your test cases list:
- Press the Button “Add Test Case” in the Editor Header.
- Or just press “Alt+t”
The maximal number of test cases that you can see on one page in the editor is currently 10.
So if you have already 10 defined and you add another one, use the Paginator in the footer of the editor to navigate to the next page.
Add a Test Case before and after other Test Cases
Sometimes you want to add a test case not just at the end but at a certain position. To achieve this use the commands “Add Before This Test Case” and “Add After This Test Case” which can be found in each context menu of a test case.
Add a Description to a Test Case
If you have created a big test model with a lot of test cases it is not easy to keep track of which representative values are combined or what that specific test case actually wants to achieve. For that we added the feature “Edit Description”. You can add a description to each test case by either clicking on the little speech bubble in the top left corner or again with the help of the context menu where you select “Edit Description”. If you have added a description you can see that the speech bubble icon turns into a filled speech bubble. After generating test code you will see that this description was added to the code.
Remove Test Cases
With the help of the context menu you can also remove a single test case, by opening the context menu of a test case and select “Remove This Test Case”. If you want to remove all test cases use the Button “Remove All Test Cases” in the editor header.
Generation of Test Cases
The previous subsection showed you how to create test cases and assign values to them by selecting representatives. However, you can also leave this task to devmate. The function “Generate Test Cases” combines test cases according to a specific algorithm. We explain the algorithm using the test model “avgspeed.tmdl”.
Positive Test Cases
Positive test cases are generated first. This means that as many test cases are generated until all representatives of all positive equivalence classes have been selected at least once in a test case. The prefix “p” is added to the name of these test cases. Since in our example all 3 input factors have a valid equivalence class and each of them has only one representative, only one active test case is created.
Negative Test Cases
Afterwards, negative test cases are generated. One representative of an invalid equivalence class is combined with random representatives of valid equivalence classes. This is repeated until all representatives of all invalid equivalence classes have been selected at least once. Negative test cases are given the prefix “n”.
Define Expected Values
Now that we know how to create test cases by combining representatives we have to define their expected outcome. The outcome may be an expected return value or the type of exception thrown by the System Under Test. Additionally, you can also check expected side effects, this is explained in the next section.
The radio buttons at the bottom of each test case allow you to specify if you expect a value to be returned or an exception to be thrown. The type of the expected return value depends on the return type of the System Under Test. Our AverageSpeed example method returns an object of type Speed. So the expected result is of type Speed as well.
The definition of expected values works exactly like the definition of representatives. So refer to Section 3c for details.
Choose an Exception as Expected Outcome
If you expect an exception to be thrown devmate allows you to define the type of the exception by choosing it from a list of known exceptions. You can search the list by typing the desired exception’s name while the list is focused.
Define Expected Side Effects
It is possible to test side effects, but first a test case must be created and populated with representatives for each input factor. Once this is done, side effects can be defined by clicking on the field next to the label “Expected Side Effects:”.
To set a side effect, the checkbox next to the input factor must be activated. The expected value must be entered in the “Expected:” field. Initially, this field contains the value that the input factor has in the test case; in addition, this value is also displayed one line above the expected in the field labelled “Input:”.
Side effects can be defined for input factors which are regarded as reference types in C#. Which types are recognised as such is defined here: Reference types – C# Reference . Since structs are not identified as reference types, it is not possible to define a side effect for them.
However, there is also the possibility to check the side effects of input factors whose types are not considered reference types by default. This is possible if the input factor contains the parameter modifier “ref” or “out”. If an input factor has these parameter modifiers, they will also be selectable in this window.
