1

This is kind of architectural and a broad question.

I have a spring rest app with three layers. (1) Front controllers (rest or mvc controllers), (2) a service layer between controllers and DAO, (3) a DAO layer which is spring data jpa repositories in my case. Now, the question is, I have written integration test for the controllers using @WebMvcTest with test slicing. For the DAO layer, I am using @DataJpaTest which is sliced testing for JPA repositories. The service layer is plain java classes so I have just unit tests with mocked DAO's.

  1. Now, is there still a good reason for doing a full integration testing which will start the whole container and hit up to the DB?

  2. I also send SpringApplicationEvents inside my application. Is there any need to test if they are working properly? And if yes, how?

  3. The service layer also controls transactions. Again, is there a need to test if transactions working as expected, and how?

Thanks in advance

Improve this question

1 Answer 1

Reset to default
2
  1. Sure, imho it is always a good idea to test your business code using the database you are targeting for usage in production environment, especially if you are using (native) queries and / or triggers. The database may behave differently to available in-memory pendants like H2 or HSQL. Also the flushing behavior / the moment when constraints are checked differ between in-memory and "native" dbs and every dialect can raise a different types of exception.

To encapsulate, resp. ease the test database handling (setup / cleanup) maybe take a look at Testcontainers.

  1. You don't have to test the event mechanism itself, the Spring guys (and gals) hopefully did that already before releasing it and if you trust them, events should work (in general). Of course there can always be a bug, but if you start to test every frameworks functionality you will never make it into production. Beside this argumentation, testing events can be handled using listeners placed below the src/test/java package which listen for the events fired by your business code. In production this test listeners won't harm the application. At least that's kind of easy for synchronous events, if it's about async events it will get tricky.

Maybe Awaitility can help out at this point.

  1. Testing transactions is in my opinion to "low level" to be tested within your Spring Boot application. But again, of course you should test that your application behaves correctly, e.g. if an exception is raised and you expect a rollback of the database state. But the transaction mechanism itself should be tested by database maintainers. If it is a well established procuct (Oracle, PostgreSQL, MySQL) it should be tested and work as expected.
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.