Spring Boot Testing — Data and Services
Chapters
I think testing is an essential thing in software development. And I’m not the only one. If you ask any developer whether tests are important or not, they would probably tell you the same thing.
But the reality is not so bright. Almost all projects that I’ve seen lack either tests’ presence or their quality. It’s not just one case. The problem is systematic.
Why does it happen? I consider that developers usually don’t pay enough attention to improving the knowledge of testing frameworks' usage. So, when it comes to verifying the business logic programmers just don’t know how to do it.
Let’s fill the gaps and see what Spring Test has prepared for us.
The code snippets are taken from this repository. You can clone it and run tests to see how it works.
Service Layer + Mocks
Mocks have become so widespread in testing environments that mocking and testing are almost considered synonyms.
Suppose that we have PersonCreateService.
PersonValidateService is our custom interface. PersonRepository is a simple Spring Data JpaRepository.
Let’s write a unit test using mocks.
Ok, that one was pretty easy. Let’s think about something more complicated. What if a user’s creation passes? That requires a bit more determination.
Firstly, we need to mock PersonRepository so saveAndFlush returns the new Person instance with a filled id field. Secondly, we need to test that the result PersonDTO contains the expected information.
It has become tricky. But there’s no time to rest yet. Assume that PersonCreateServiceImpl has been enhanced with createFamily method.
It needs tests too. Let’s try to write one.
When I look at this code I see nothing but just nonsense. The data flow is so complicated that it’s almost impossible to get what the test is really doing. More than that, there is no testing but verifying that some particular methods were called the defined times. “What’s the difference?” you may ask. Imagine that saveAndFlush method execution was replaced with the custom one that updates the entity and saves the previous state in the archive table (e.g. saveWithArchiving). Although the business logic is the same the test would fail due to the fact the new method has not been mocked.
Perhaps the last statement was not convincing enough. Let’s see the declaration of Person entity.
It has PrePersist callback that sets the date of creation just before inserting a new record in the database. The problem is that it cannot be tested with mocks. The logic is being invoked by the JPA provider internally. Mocks just cannot imitate this behavior.
So, let’s draw the conclusions. Mocks are perfect for testing those functions that you have control for. These are usually user-defined services (e.g. PersonValidateService). Spring Data and JPA generate lots of stuff in runtime. Mocks won’t help you to test it.
Service Layer + H2 Database
If you have a service that is ought to interact with the database, the only way to truly test it is to run it against the real DB instance. H2 DB is the first thing that comes to mind.
Thankfully we don’t need any complex configurations and tricky beans declaration to run a database in the test environment. Spring Boot takes care of it.
DataJpaTest
Where do we start? Firstly, we need to declare the test suite.
@DataJpaTest annotation does the magic here. And specifically, there are 4 points.
- Launching the embedded instance of the H2 database.
- Creating the database schema according to declared entity classes.
- Adding all repositories beans to the application context.
- Wrapping the whole test suite with
@Transactionalannotation. So, each test execution becomes independent.
You have probably noticed the @MockBean annotation. That’s the Spring feature that not only mocks the interface but also adds it to the application context. So, it can be auto-wired by other beans during the test run.
Now we need to instantiate the service that is about to test.
In my opinion, the most flexible solution provides the @TestConfiguration annotation. It allows us to modify the existing application context. When PersonCreateService is added, it can be easily injected with @Autowire.
Ok, let’s start with a simple happy path test of createFamily method.
As you can see, this test is much cleaner, shorter, and easier to understand than one using mocks. More than that, we are now able to test Hibernate callbacks (e.g. @PrePersist).
Well, this one was a cake. But what if ValidationFailedException occurs? It means that the transaction should be rolled back. Let’s find this out.
The execution should fail on "John" creation. It means the total number of people has to be equal to 0 because the exception throwing rolls back the transaction.
expected: <0> but was: <2>
Expected :0
Actual :2Something went wrong. Seems like the transaction has not been rolled back for some reason. And it’s true.
I’ve mentioned that @DataJpaTest wraps the suite with the @Transactional. So, the test suite and the service are both transactional. The default propagation level for the annotation is REQUIRED. It means that calling another transactional method does not start a new transaction. Instead, it continues to execute SQL statements in the current one. ValidationFailedException occurring does not roll back the transaction because the exception does not leave the scope of it. So, the count returns 2 instead of 0.
I have described this phenomenon in my article “Spring Data — Transactional Caveats”.
What can we do about it? Actually, @DataJpaTest usage won’t allow us to do anything about it. We could mark the PersonCreateService.createFamily transaction propagation as REQUIRES_NEW. That solves the problem with the current test but adds new ones. You can find more examples in the repository that I tagged at the beginning of the article.
If @DataJpaTest causes so weird problems then what’s the purpose of it? Well, its name describes the goal. It’s ought to be used with repository tests.
See? That fits perfectly. The test executes a single SQL statement. In this case, transactional behavior of@DataJpaTest becomes convenient. But service layers are far more complicated. And we need a different tool for that.
SpringBootTest
Let’s rewrite the test declaration a little bit.
There are some differences with the @DataJpaTest alternative.
The @SpringBootTest annotation launches the whole Spring context and not only JPA repositories. Another important thing is that it does not wrap the test suite with the @Transactional.The webEnvironment = WebEnvironment.NONE is a slight optimization. We don’t need the web layer in the test case. So, there is no need to spend resources on that.
The @AutoConfigureTestDatabase annotation configures the embedded H2 database and creates the schema according to defined entities. @DataJpaTest already includes it, so it’s redundant to declare them both (unless we want to parameterize @AutoConfigureTestDatabase but that’s out of scope).
You may also have noticed that we just auto-wired PersonCreateService without any additional configurations. Due to the fact that @SpringBootTest instantiate every bean by default the service is already present in the application context.
The database reset in @BeforeEach callback is required since @SpringBootTest does not provide transactional behavior. But we need to keep the table clean between tests run.
So, let’s put the tests from the @DataJpaTest example and see how it works.
Everything works like a charm.
All of our test cases assumed that PersonValidateService.checkUserCreation has a simple logic of checking the input parameters. But in reality, this might not be true. The service may interact with the database as well in order to check preconditions. So, let’s imitate the behavior.
Suppose that the validator does not allow create a new person if there is one with the same last name. To test this scenario we need to properly mock the PersonValidateService and insert a family member in advance before calling the PersonCreateService.createFamily method.
It works! Besides, here is a spoiler. It does not work with @DataJpaTest no matter what configurations you apply. You can find the example in the repository.
Edit 14.07.2021
Actually,
@DataJpaTestcan run non-transactionally. You just need to add@Transactional(propagation = NOT_SUPPORTED)to the test class. Renan Franca thanks for the hint!
@DataJpaTest
@Transactional(propagation = Propagation.NOT_SUPPORTED)
class PersonCreateServiceImplTestH2 {
@Autowired
private PersonRepository personRepository;
@MockBean
private PersonValidateService personValidateService;
@Autowired
private PersonCreateService personCreateService;
@BeforeEach
void beforeEach() {
personRepository.deleteAll();
}
@TestConfiguration
static class Config {
@Bean
public PersonCreateService personCreateService(
PersonRepository personRepository,
PersonValidateService personValidateService
) {
return new PersonCreateServiceImpl(personValidateService, personRepository);
}
} // test cases...
}
Conclusion
Thank you for reading! That’s a quite long article and I’m glad that you made it through. Next time we’re going to discuss Testcontainers integration with Spring Test. If you have any questions or suggestions, please leave your comments down below. See you next time!
