Awesome and well articulated response. Love it.

There are a few threads to pull here:

Is an integration test the best way to test the full e2e behavior of an api call? Yep.

Now, depending on the size (and architecture) of your system, the full test suite of into tests could take like, 10 hours.

And even then, you’re STILL probably mocking something (direct seeding bombs into the db). Full setup of all life cycles of all your entities using their associated entities (bombs, wires, wire clippers, bomb diffusers, their rank, their bosses, their diffusion history, etc…)

So they’re expensive, and if you really look you’re probably still cheating some steps anyways.

Another thread to pull on is what are you mocking in your tests to begin with, and if they’re not resulting in valuable test results then that goes back to one of my original points being that you might have suboptimal patterns in your production code.

Like, what logic governs bomb diffusion and where does it live? Are you mocking the right thing? If you have to mock the wrong thing… WHY? The ritual of writing those tests give you the first whiff of a potential smell.

I tell my guys not to test implementation: test behaviour. Test contract adherence. If that’s hard, no problem, message me let’s review it. Maybe a behavior they’re trying to test legitimately should be an int test. More often than not, their design is demanding to mock something that should be decomposed further, and then composed with dependency injections that are where the units that should ACTUALLY be mocked are the things that get mocked and injected, so the unit tests are actually testing the BEHAVIORS we want to pin rather than implementations. Composition and single responsibility principal are what enable unit tests to pull their weight.

Edit: I’m so passionate on the subject that if you scribbled up a scratch example and pinged me a github link I’d genuinely review it.