Writing BE tests

[ctapobep]

Test Pyramid

How not to write tests

In most projects there are 2 conflicting ideas:

1. Write unit tests mostly. And if we need a database or an external service or some other class, then mock those dependencies. But mocking is a problem:
   1. The mocked behavior doesn't necessarily match the production code and we basically test our test
   2. Mocking violates encapsulation. And so because our tests know the internals of the implementation (what objects the method-under-tests uses and and which methods it invokes), if we refactor the production code we break the tests. Even though the behavior didn't necessarily change.
2. Write high-level tests mostly - with real dependencies like database or other Java objects. It doesn't have the problems related to the mocks and we do test the real production code. But:
   1. Such tests a very slow, which makes the build very slow
   2. It's hard to find where the problem is when the tests fails - because a lot of code is invoked in the tests directly or transitively.
   3. These tests often require a lot of set up which makes them harder to write

Creating a Test Pyramid with Rich Model

Our approach is to build a Test Pyramid, follow the Rich Model (the logic isn't in Services, but in the domain model: Entity, Value Objects, etc) and almost never use mocks:

1. If possible to keep logic in the entity or value objects - we keep it there instead of putting it into the services
2. This allows us to write a lot of unit tests without mocks
3. Then in high-level tests we need to check that our Service/API layer does invoke that domain logic properly - so at least one high-level (possibly more) tests need to be written too

Also, to simplify and speed up our code a lot of logic is embedded in SQL, those for sure we need to test on DAO layer, and therefore the tests will be high level.

For more info read:

• Anemic architecture - enemy of testing
• Building Test Pyramid to optimize automated testing

API Tests

We use RestAssured + MockMVC to test the API layer. For each API class we create a Client. Most methods of such Clients are of 2 types.

General purpose methods: they can be used to test unsuccessful scenarios, and so they can’t check the status code. Neither can they return the DTO that the endpoint usually returns - because oftentimes it’s the error that needs to be returned. Example:

public MockMvcResponse getOrFail(String id) {  
   return given().get("/api/batch/" \+ id).thenReturn();  
}  

But in most cases we want the happy path. So we also create happy path methods: invoke an endpoint and return a DTO or nothing at all. Such methods must check the response code.

public BatchDto get(String id) {
    MockMvcResponse response = getOrFail(id);
    HttpErrorException.assertSuccessful(response);
    return response.as(BatchDto.class);
}