In this video I’m literally coding in the park while I work through some very real backend engineer problems: tech debt and integration tests that “someone forgot” to write. I’m working on analytics integration tests in a codebase that somehow has three different analytics systems (why three, not just one? I don’t know). None of them had integration tests, so now I’m writing them to make sure that when requests hit our API, we process everything correctly and write the right analytics events to each platform. I break down what an integration test actually is: testing a feature end-to-end, which can mean different things depending on your team. For me, end-to-end is usually “request comes into my service → we do a bunch of stuff → response goes out,” plus verifying the internal side effects (like analytics being emitted correctly). I talk about how these tests are built (dependencies, what to mock vs keep live, sample JSON responses, verifying calls and outputs), why engineers hate them (context switching, building a mental map of the whole system, outdated diagrams), and why they still matter (analytics drives product decisions and kept breaking on deploy). Also yes, I still prefer my 100 assert statements sometimes.