Some test technology also support crafting maintainable tests. AssertJ, for example, provides the possibility to create custom assertions. In our test case the car needs to verify the correct engine and color encapsulated into car specifications. Custom assertions can decrease overall duplication in the test scope.

The following shows a custom AssertJ assertion for verifying a car:

import org.assertj.core.api.AbstractAssert;

public class CarAssert extends AbstractAssert<CarAssert, Car> {

    public CarAssert(Car actual) {
        super(actual, CarAssert.class);
    }

    public static CarAssert assertThat(Car actual) {
        return new CarAssert(actual);
    }

    public CarAssert isEnvironmentalFriendly() {
        isNotNull();

        if (actual.getSpecification().getEngine() != EngineType.ELECTRIC) {
            failWithMessage("Expected car with environmental friendly engine but was <%s>",
                    actual.getEngine());
        }

        return this;
    }

    public CarAssert satisfies(Specification spec) {
        ...
    }

    public CarAssert hasColor(Color color) {
        isNotNull();

        if (!Objects.equals(actual.getColor(), color)) {
            failWithMessage("Expected car's color to be <%s> but was <%s>",
                    color, actual.getColor());
        }

        return this;
    }

    public CarAssert hasEngine(EngineType type) {
        ...
    }
}

The assertion is then usable within the test scope. The correct static import of the CarAssert class has to be chosen for the assertThat() method:

assertThat(car)
        .hasColor(Color.BLACK)
        .isEnvironmentalFriendly();

The examples in this chapter showed tests written mainly with Java, JUnit, and Mockito, with the exception of embedded application containers and Gatling. There are dozens of other test technologies that uses different frameworks as well as dynamic JVM languages.

A famous example of this the Spock Testing Framework which uses Groovy. The motivation behind this technology was to write leaner, more maintainable tests. Since dynamic JVM languages such as Groovy or Scala are less verbose than plain Java, this idea sounds reasonable.

Test frameworks, such as Spock, indeed result in test cases that require minimal code. They make use of dynamic JVM language features such as less-constraint method names such as def "car X123A234 should be created"(). Spock testing also provides clear readability with low effort.

However, readable tests are achievable with all test technologies if test code quality is minded. Maintainability, in particular, is rather a question of well-crafted test cases and proper abstraction layers than of the technology being used. Once test cases become quite complex, the impact of the technology on maintainability becomes less relevant.

When choosing test technology, the team's familiarity with the technology should also be considered. At the time of writing, enterprise Java developers are usually less familiar with dynamic JVM languages.

However, the test code quality should be more important than the used technology. Applying good practices of software engineering to tests should be considered as mandatory, using other test frameworks as optional. Refactoring test cases frequently increases the maintainability and reusability of test components and ultimately the quality of the software project.