Testing is a very important part of the SDLC. Sometimes I’ve seen projects where there are only unit tests, omitting integration tests.
When I asked the development teams why they weren’t there, I got different answers:
We have a good coverage of unit tests, that’s enough We had these tests but they were flaky, so we don’t develop them Its hard to write first test and we have no time now to write them issue on production
Good unit test coverage is not enough in most cases.
Unit tests provide certainty in Core places where we have business rules.
They ensure us that logic and calculation works as expected. They cannot check integration between components because they are work in isolation.
Integrations tests can ensure integration of components work properly. In addition:
- dependency injection registration
- database configuration
- data persistance
- schema migrations
- http clients etc.
Without integrations tests we are not enough confident to put our code to production, without manual regression tests. That makes real CI/CD impossible.
According to test pyramid.
I would use suggest a lot of unit tests where we have logic + a few integration tests to cover e.g happy path with one variant of logic and negative path.
If there is no logic i will write only integrations tests.
There are many ready-made libraries that make our lives easier.
For example, WireMock can be used to mock responses from the external systems that we are integrating with.
When we use events for integration we can use queue simulator and simulate event publishing. Test our whole module in isolation.
To sum up, Unit test can check logic but won’t tell us that application behaves correctly. Unit Test with Integration tests can do it. With such a combination plugged into CI/CD pipeline you and your team should be pretty confident when you release new version of your code. First test can be difficult to write but it’s is worth it. If your team will embrace the speed of implementations and thus the quality of the code will increase significantly.