How Unit Regression Tests work
The first blog in this series introduced unit regression tests-a new type of test that helps you identify changes in your code’s behavior. The main difference between traditional unit tests and unit regression tests is that unit regression tests are automatically created by Diffblue Cover. This blog will show you how it’s done.
Mapping code behavior
Diffblue Cover’s AI engine can quickly write a suite of unit tests that are derived from existing code, so they reflect the current functionality of the program. This primary map of the code is used to test new commits, for example, to see what changed.
Because unit regression tests will only be created en masse, the individual tests themselves matter less than their collective capability as a net for catching regressions. The breadth and depth of tests that can be generated by Diffblue Cover quickly encompasses a wide variety of scenarios, including edge cases, corner cases and simpler boilerplate code that might have been missed (either intentionally due to cost, or accidentally) by a human.
What do unit regression tests look like?
Tests created by Diffblue Cover always compile, run quickly, and are easy to understand. Here’s an example of a test created by Diffblue Cover for JUnit.
This unit of code checks the current balance and open status of a bank account:
public void takeFromBalance(final long amount) throws AccountException {
if (getAccountState() != AccountState.OPEN) {
throw new AccountException("Cannot continue, account is closed.");
}
if (currentBalance - amount < 0) {
throw new AccountException("Not enough funds");
}
currentBalance -= amount;
}A test for this code that was automatically created by Diffblue Cover is below:
@Test
public void takeFromBalanceTest() throws AccountException {
// Arrange
Account account = new Account(1234567890L, new Client("Bob"), 10L);
// Act
account.takeFromBalance(10L);
// Assert
assertEquals(0L, account.getCurrentBalance());
}In this test, the Account object has been initialized with real-world value of an account number, the client name and the account current balance.
In ‘// Act', the method takeFromBalance is being called with 10, which will exercise the method logic.
In ‘// Assert ', the test is asserting that if you take 10 away from the Account balance of 10, you will be left with 0.
Protection against regressions
This test demonstrates how the method is meant to behave. If the method functionality were to be changed in an unintended way, this test would fail: For example, a trivial but common mistake is using the wrong operator; just changing the operator in currentBalance += amount would cause the test to fail, alerting the developer to a regression.
You might also be interested in:
- Introducing Unit Regression tests
- What are the different types of tests?
- How to measure code coverage with JaCoCo
- How to write your first Java unit test
- What’s the purpose of unit testing?
- Shifting Left with Unit Regression Tests
- The Best Unit Testing Tutorials for Spring and Spring Boot
- 4 Reasons Why Unit Testing is Worth It
