12 posts tagged with "Spring Boot"

TL;DR: Testcontainers changed Spring Boot integration testing by replacing in-memory databases like H2 with real Docker containers. But starting a container is only part of the work. Seeding it with realistic data is still difficult. This post explores when to use Testcontainers, when to use pure trace replay, and how BitDive combines both to give you real databases auto-seeded with production data.

TL;DR: Testing Spring Cloud OpenFeign clients is difficult to get right. Mocking the Java interface misses serialization and interceptor logic. WireMock tests the full HTTP stack but requires constant manual updates to JSON stubs. A more reliable alternative is runtime replay. You capture real HTTP exchanges from production and virtualize the Feign boundaries during your Spring Boot integration tests.

TL;DR: Trace-based testing is a software testing approach where tests are built from real execution traces captured from a running application. Instead of writing mock data manually or using AI to guess test cases from source code, trace-based testing records actual method calls, SQL queries, and API responses, then replays them as standard JUnit tests.

Teams usually discover trace-based testing when they hit the same wall: green unit tests, green code review, and still a production regression after a harmless-looking change.

TL;DR: The hardest part of an N+1 bug is not fixing it. The hardest part is noticing it before production. A Spring Boot endpoint can return the correct JSON, pass unit tests, and still execute 243 SQL queries instead of 1. This post shows how to detect N+1 patterns from real traces, choose the right fix in Spring Data JPA, and verify that the optimization did not change the API output.

TL;DR: In the industry, there is a weird habit: if a tool can generate tests, it is considered automatically useful. If you have 300 new .java files in your repo after recording a scenario, the team assumes they have "more quality." They are wrong. Automated test generation often turns into a source of engineering pain, cluttering repositories and burying real regressions in noise. There is a more mature path: capture real execution traces, store them as data, and replay them dynamically.

TL;DR: Bumping the Spring Boot version in pom.xml takes 10 seconds. Finding out that the upgrade silently changed your JSON serialization, broke your security filters, or altered your error responses takes days. This post covers seven categories of silent breaking changes that Spring Boot upgrades introduce, and a practical workflow to catch them before production.

TL;DR: Your integration test hits the happy path: 200 OK, correct response body, all good. But what happens when the downstream returns a 404? A 500? A 503 with retry-after? If your service parses the error response body, and the body format changes silently, you will find out at 3 AM when the retry storm starts. Error contracts are just as important as success contracts, and almost nobody tests them.

TL;DR: Your service compiles. Your unit tests pass. Your integration tests are green. But a single line in your ObjectMapper configuration just changed what every outgoing HTTP request looks like. The downstream service cannot parse the payload anymore, and you will find out in production. Here are five Jackson configuration changes that cause this, with exact before/after JSON for each.

TL;DR: The most dangerous bugs in microservices are not inside a service. They are between services. A code change can make a service pass all its local tests while silently altering what it sends to downstream APIs: different payload, missing header, changed error format. These regressions are invisible to unit tests, hard to catch with contract tests, and expensive in production. BitDive detects them by capturing real HTTP exchanges in execution traces and comparing them before and after a code change.

TL;DR: Boot the full Spring context. Stub only what lives outside your service boundary: Feign clients, external HTTP APIs, outbound Kafka. Then hit the service through its real HTTP endpoint and verify the entire chain: controller, validation, service logic, @Transactional, repository, database write, response serialization. This is what Spring calls an integration test. It catches the class of bugs that unit tests structurally miss: broken configs, silent serialization changes, transaction proxy bypass, security filter misconfiguration, and DTO contract drift.