3 ms·
The trivial realities of the actual world may chill my heart to the bone, but even I can accept this sad inevitability ;) The thing is, the fact that your code
by WalterSear 9y ago
The trivial realities of the actual world may chill my heart to the bone, but even I can accept this sad inevitability ;)
The thing is, the fact that your code relies on someone else's, and that their code can change out from under you is exactly why you need separation in your tests and modularity in your code. Using the system I am describing, you are still working with 'real world' data - you are just asserting it in advance (since the real world inputs correlated with the inputs of your integration suite via the edge tests) and ring fencing your endpoints.
I've actually been part of a software team driven wild by unknown changes to infrastructure endpoints, causing failure of the integration test suite. And then by the brittleness of an integration suite too tightly coupled to inputs.
I've also worked with test suites that failed when run after business hours, but only during Atlantic DST, for the same reasons. :|
- mcphage 9y ago> I've actually been part of a software team driven wild by unknown changes to infrastructure endpoints, causing failure of the integration test suite. Now imagine that your tests hadn't been so tightly coupled, and there were unknown changes to infrastructure endpoints. Suddenly your code starts failing, and you can't tell why, because your test suite is all green.