Today I’m coding in my apartment as a backend engineer, and (for reasons I still don’t fully understand) I picked up another integration test story. This one is tied to a migration we did a few months ago where we swapped a backend dependency from “service A” to “service Y.” At the time, we wrote unit tests, pushed hard to get the migration into production (faster service, fewer calls, better data), and left a bunch of integration tests as tech debt—often literally marked with an @Disabled annotation. In this video I walk through how I approach getting those tests back into a healthy state: find the disabled tests, update mocks from the old service format to the new one, and keep the actual assertions intact. The whole point is to prove the output to the user didn’t change even though the dependency did. The biggest unlock here is creating a clear field mapping between the two JSON responses (what renamed, what disappeared, and what needs manual translation), then validating that mapping with the team. I also answer a common testing question: what to do about databases. If your DB is effectively an outgoing request, you can mock it—but if your workflow is more complex (write, read, modify, re-write), a real test environment can be worth it. Like most engineering decisions: it’s a tradeoff between realism and reliability.