How DevMate changes your approach to unit and integration tests without changing how you work.

Requirements are key

Code should be based on a set of requirements, hopefully well documented. DevMate helps you to

• take those requirements
• map them to so-called Equivalence Classes and Representatives
• generate test cases automatically or manually
• generate instantly runnable tests.

We'll skip to ahead and see what a configured test definition looks like. An experienced DevMate needs five to ten minutes to fully configure.

Let's look at how we got there.

Testing a method

From your IDE, you right click the method(s) you want to test and select Test with DevMate. Let's start configuring.

Below is the basic structure when we start to configure a test.

1. DevMate detects the name of the parent class AllTogether.
2. The method to you want to test (checkCredit).
3. The method's arguments

Input Equivalence Classes

You then define Equivalence Classes. Within each Equivalence Class, you define one or more Representative values.

For our example, we are offering credit to people between 18 and 25, and 26 and older. We offer different levels of credit and maximum repayment periods depending on their age.

We instantiate AllTogether and then call checkCredit() with the amount and duration of the loan.

1. We create an Equivalence Class for the 18-25 range. Below that we've also done the same for 26+.
2. Using a popup dialog, we set the Representative value using AllTogether's constructor.
3. We do the same for the creditSought parameter. We have first created a valid Equivalence Class that is valid for any age.
4. We then created invalid ones with suitable Representatives.

This process is repeated as for all parameters in order to meet the requirements.

Output Equivalence Classes

We then define Equivalence Classes for the output or result of the method call.

1. The Output section deals with everything that can happen when the method terminates.
2. DevMate knows that checkCredit() returns an object of type CreditReturnStatus. We've added a valid and an invalid Equivalence Class and defined a Representative for each one.
3. DevMate also handles Exceptions very elegantly.
4. You can also code your own Custom Assertions if you want to handle more complex examples in code.

Auto Generating Test Cases

Once the Equivalence Classes have been defined, we can automatically or manually generate the test cases. You will usually let DevMate do this automatically. It uses a best practice approach called Pairwise Combination. Put simply, it only generates the test cases you need. No more and no less.

1. We can auto generate the test cases by pressing this button
2. It has generated six test cases for us as columns. We have given friendly labels to each one. This makes the test definition easy to understand, even years later.
3. For each test case, we click on the radio button in each of the Instances, Input and Output sections, thereby specifying what values we want to use and what we expect to be output.
4. That's it. We can now simply generate the test code with another press of a button.

Generated Test Code

DevMate generates parameterized test code. This is a highly effective and best practice way of testing. Each test case is passed as a set of parameters into standard testing functions.

1. Shows an example of how a Custom Assertion can be specified and quickly edited in your IDE.
2. This example has two Scenarios (see below). This one is called ValidatePersonTest.
3. And the second Scenario is the CheckCreditTest we showed earlier.
4. Everything below this line does not really need to be looked at, but it's easy to understand if you want or need to.
5. We're showing IntelliJ and Java but the same principle applies to Visual Studio and C#. We can run an individual Scenario's test, if you have more than one.
6. Or you can run all Scenarios.

Running the Test

So let's run the test from the IDE. This uses whatever test runner you like to use. This also means that it fits into CI/CD pipelines as we are not performing any black magic that can get in the way.

This example shows the test having run and two Scenarios and each one's test cases having executed and passed.

Notice how the tests are nicely labelled. Any labelling we do in DevMate not only makes it easy to understand in DevMate, but the code and test output is automatically documented as well.

Multiple Scenarios

You will often need flexibility when defining a test. This means you will want to perform various sub-tests within the context of a single, larger test. This is where Scenarios come in.

A common situation is where you want to validate an instance with all possible valid and invalid cases. After this, you want to perform a method test but only with valid cases. If you combined everything into a single scenario, you would end up with a large number of test cases and a more complex setup.

1. The currently selected Scenario is ValidatePerson.
2. We've defined a set of valid and invalid Equivalence Classes for instantiating AllTogether.
3. We then call the validatePerson() method and specify what outputs match each instantiation for each test case.
4. We would then switch to the CheckCredit scenario, which tests the checkCredit() method we looked at earlier.

Multiple Methods

Within a scenario, you can call different methods sequentially. These methods can run independently or the output of one method can be passed to a later method.

1. We first call multiplyPositiveByTen() and pass in a value of 3.
2. We then call multiplyPositiveByTen() again (you can call any method you like).
3. Notice how we are taking the return value from the first method call (labelled as M1) and using this as the input value for the int input parameter. Methods do not have to be linked like this.

Tutorials

We have a large collection of tutorials that explain how to use DevMate step by step.

‍