Test Doubles and the Network

Your billing page is covered by twenty passing tests. In production, it has been displaying NaN € for three days. You open the tests: they mock the HTTP client with vi.mock, and the test double returns { montant: 1290 }. The real service, since a back-end migration last month, returns { montant: "1290.00", devise: "EUR" }. Your tests never verified the real contract: they verified that your code works with the data you invented for it.

This is the central risk of any test double, and it is structural: you replace a dependency with a simplified version, which means you remove from your test surface exactly the part you don't control. The question is never "should I mock?" but "at what level should I cut?", and the answer is almost always: as low as possible. Intercepting at the HTTP level lets your client, your serialization, your error handling, and your response parsing keep running — in other words, all the code where bugs actually live. Mocking the module that calls the API removes all of that at once.