Testing Approach

The server application is primarily tested using BDD tests. Smaller tests for more complex algorithms are carried out using jUnit.

Principles

The following principles are at the forefront of application testing:

BDD Testing

BDD stands for Behaviour-Driven-Development.

The basic idea with BDD tests is to test the behavior of the application, rather than running a test to find out that passing arguments gives a specific value, and to bridge the gap between business people and technicians.

To achieve this, it is possible to write tests (or rather expectations or behaviors) in "normal" sentences. These sentences are written in Gherkin language.

By defining the behavior, the application can be tested to see if everything works as expected without going too deeply into the details of the implementation. This also enables refactorings or changes to classes (e.g. extracting a large method into several smaller methods) without interrupting the tests.

This has some benefits:

Changes to the code that don't change the behavior can be tested without changing the tests (which often results in writing a test that validates the refactored feature, but not the functionality)
Business people can express what they expect from a function and how it should react
Engineers write understandable tests
With library support, this is a very simple task
All stakeholders in the product should work together, and not hand over the application to the next person
The specified scenarios are also the acceptance criteria for the feature

BDD tests are performed with the Cucumber framework, which supports the writing of comprehensible sentences using the so-called Gherkin syntax.

In particular, the following Cucumber framework is used for API tests in Spring applications, as it has already standardized 95% of all required sentences: BDD Cucumber Gherkin Lib

BDD vs. unit testing

Let's take an example:

@Test
void shouldRejectIfNoTokenWasGiven() throws Exception {
    mockMvc.perform(MockMvcRequestBuilders.get("/api/v1/myendpoint")
        .contentType(MediaType.APPLICATION_JSON)
        .accept(MediaType.APPLICATION_JSON))
        .andExpect(status().is(HttpStatus.UNAUTHORIZED.value()));
}

For business people, it's just a collection of characters. The result they see is that shouldRejectIfNoTokenWasGiven has done something.

What does that mean? Nobody understands at first! How was it tested? Nobody understands at first!

Even if a customer asks for tests, it is good to have comprehensible test documentation or comprehensible tests.

With Cucumber, the same test looks like this:

Feature: Security Test
    Background:
        Given that all URLs are relative to "/api/v1"

    Scenario: Access without token should be rejected
        When executing a GET call to "/myendpoint"
        Then I ensure that the status code of the response is 401

It's much easier to understand this time, isn't it?

Last modified: 11 December 2023