Testing
A fast suite that catches real regressions, not a slow suite that merely reassures.
REST API Testing
There are two ways to get testing wrong in a Spring Boot API, and they are less alike than you might think.
The first is not writing any tests. Nobody admits to it, everyone does it for a while, and the symptom is familiar: every change becomes a negotiation, because nobody knows what it will break.
The second is more insidious because it looks like rigor. Everything is annotated with @SpringBootTest, every test starts the full context, the suite takes eleven minutes, the team stops running it locally, and half the tests verify that Spring can map a URL, which Spring already guarantees. You've paid the price of testing without getting any of the value: a slow suite that nobody runs protects nothing.
The right balance comes from a simple question, asked test by test: what code that I wrote does this test protect? If the answer is "the logic that calculates the return date," a unit test that runs in a few milliseconds is enough. If it's "the serialization, validation, and status code of my controller," a @WebMvcTest slice is the right tool. If it's "my JPQL query works on PostgreSQL," you need a real PostgreSQL, and Testcontainers provides it.
Comments
Comments are powered by GitHub Discussions
Sign in with GitHub to join the discussion