Few hints on how to write better tests:
1. Don't use "test" prefix for test methods. This had to be done in JUnit 3 (!) but now it only adds noise. Instead use method names that express the intent.
1. Don't use "test" prefix for test methods. This had to be done in JUnit 3 (!) but now it only adds noise. Instead use method names that express the intent.
2. Group related tests together with JUnit 5 @nested annotation. This will add structure and save you from repetition
3. Use AssertJ. JUnit assertions are not bad but AssertJ will make your tests much cleaner and easier to maintain assertj.github.io/doc/
4. Structure tests in given, when, then format (or arrange, act, assert). Especially make sure that assert part actually takes place. Tests that do not verify the outcome are harmful as they create impression that the code is tested when it's actually not.
5. Don't overuse Mocks.
When your application is mainly glueing together different technologies and very little logic, perhaps it's better to write integration test instead.
When your application is mainly glueing together different technologies and very little logic, perhaps it's better to write integration test instead.
6. Don't overuse Mocks especially when you use JPA
When mocking JPA repositories, it's very simple to create good looking tests that pass, but in production the application will behave completely differently. Be careful.
When mocking JPA repositories, it's very simple to create good looking tests that pass, but in production the application will behave completely differently. Be careful.
7. Use code coverage tools to ensure that you did not miss anything.
Code coverage is not meant to tell how much of your code is tested but rather which parts are for sure untested. Run your tests with coverage in @intellijidea
Code coverage is not meant to tell how much of your code is tested but rather which parts are for sure untested. Run your tests with coverage in @intellijidea
8. .. or use TDD - this way you can be sure that all production code is tested.
9. Learn about Mockito Spies. You'll find them useful when testing integration with message brokers
baeldung.com/mockito-spy
baeldung.com/mockito-spy
10. When you have flaky test (test that sometimes succeeds, sometimes fails) and you believe you fixed it, use @RepeatedTest from JUnit, with some high number of repetitions to ensure that your fix *really* works.
11. When writing @DataJpaTests, turn on SQL logging. You'll be surprised that some of your tests do not execute any SQL statements at all. Do not underestimate JPA trickiness.
12. "Unit tests were green" type of fuckups are real. Don't rely solely on unit testing or you'll end up in a bad place. Write integration tests, use @testcontainers, create few some tests that verify system end to end.
That's all I had in mind at the moment.
I am just scratching the surface so you're welcome to add your hints that others can learn from!
I am just scratching the surface so you're welcome to add your hints that others can learn from!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
