Testing is more than checking the correctness of your code. Next to validating correctness, writing tests is also good for:

  • Designing better software because to test software easily, it will have to be more loosely coupled, making it easier to change
  • Instil confidence in developers to make changes to the software system

It’s perfectly fine to not have any tests when creating a quick 1-off script, but once you expect software to live for a longer time, testing becomes a necessity. The book Software Engineering at Google explains this very well:

Unit tests begin to make sense for software with an expected lifespan from hours on up. At the minutes level (for small scripts), manual testing is most common, and the SUT usually runs locally […]. The remaining larger tests all provide value for longer-lived software […].

Testing Strategies

Microservices

The article from Spotify about testing microservices introduces the concept of a testing honeycomb instead of the classic testing triangle. The argument is that for microservices the “unit of code” is the Microservice itself, so there should be a bigger emphasis on integration testing. Although I don’t agree with some points made in the article such as the downsides of having too many unit tests, I do think that putting a bigger emphasis on integration testing in Microservices makes a lot of sense.

An example of this idea in action is 🧪 Kotlin Spring Boot Integration Testing with WireMock.

Test Types

Types of tests arranged from low-level to high-level based on the definition used in the Spotify article on testing microservices:

  • Unit
  • Integration (also sometimes called Functional Tests)
  • Integrated

Integrated tests

The downside of integrated tests is that they very easily become very brittle. When the system you depend on goes down, the tests will also fail, even though the code works correctly.

Unit Tests

Related articles: