Why do I say don’t over-rely on or blindly trust unit tests? It starts with a merge request. GitHub’s Dependabot keeps your application secure and always up to date, meaning it automatically creates merge requests to change my Maven dependency versions. And so the story begins.
Automatic Upgrade Hoxton.SR3 to Hoxton.SR6
GitHub’s Dependabot automatically created a merge request: build(deps): bump spring-cloud-dependencies from Hoxton.SR3 to Hoxton.SR6. Because I had automatic CI checks, compilation passed, unit tests passed, and the previous few merges were approved without conflicts or failures, I clicked merge. That automatically upgraded me from Spring Cloud Hoxton.SR3 to Spring Cloud Hoxton.SR6. Seeing all unit tests in a passing state, everything seemed peaceful.
The Weird Exceptions Began
After pulling the production code to local, all kinds of weird failures began. Calls between microservices all returned 401 Forbidden, and OAuth2 token validation never passed. I once thought it was caused by one of my business changes. I spent about half a day debugging this failure, then suddenly wondered: could it be because of the Spring Cloud upgrade? Because I didn’t know what the latest Hoxton.SR6 changed and upgraded without reading any docs, I tried downgrading to Hoxton.SR3 — and sure enough, everything was back to normal.
Don’t Over-Rely on or Blindly Trust Unit Tests
From this journey of finding the culprit, I learned a lot: compilation passing doesn’t mean your code is completely correct, and unit tests passing doesn’t mean your code is flawless — manual testing is still essential. The reason this wasted half a day is that unit tests only run inside each service, while a microservice is a whole. This time, the OAuth2 token validation failure could only be found after the whole microservice was integrated; automated unit tests couldn’t catch it.