With a few colleagues we recently discussed a few approaches to testing Spring Boot applications using the example of a simple CRUD API. We tend to normally do
- unit testing using Mockito, which typically means that all dependencies of a class are mocked
- integration tests using tools such as Testcontainers and RestAssured. Run dependencies such as a database in a testcontainer, make API calls using rest assured and check what ended up in the database by having some code that connects to the database directly (not via the CRUD API)
With that approach, both the unit and the integration tests don't have any dependencies on other application code and test exactly what they are supposed to test.
But there are also people who love the @SpringBootTest annotation. It's used in a lot of tutorials, so naturally junior developers often end up using it. It's useful for some special cases, but in my opinion it encourages bad testing practices. The main issue I have with it that it easily lets you 1. load and 2. modify the entire application context. It leads to really smelly tests written by inexperienced developers, that end up just autowiring a lot of the application code dependencies and use those for assertions.
Simple example: Someone might write a test by spinning a database up with Testcontainers, making an API call to insert some data and use the autowired repository to check if the data inserted is correct. What they don't think about is that as they are using application code to verify application code, then if the application code is buggy the tests are buggy and a potential issue might not be caught.
So in short, my feeling is that @SpringBootTest encourages bad testing practices by making it way to easy to use application code in places where really it shouldn't be used. Am I right or do I just not get what they are trying to do there?
submitted by /u/YNedderhoff
[link] [comments]
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/3AstlsT