52 ms·
Go ahead. Don't mock that external service that you rely on for an API. Now you need to have multiple keys, one for each developer, or share keys separate from
by jasonlotito 2y ago
Go ahead. Don't mock that external service that you rely on for an API. Now you need to have multiple keys, one for each developer, or share keys separate from various environments? Does it not offer dev/test/staging/prod keys? Well, now you need to share those keys. Does it only offer Prod keys? Now you are stuck sharing that. API request limits? Now you are eating through that just to run tests.
And let's not forget that testing things locally means you are mocking the network, or lack-thereof. "Mocking is an anti-pattern" is a great sentiment if you ignore costs or restrictions in the real world.
- bottlepalm 2y agoAlso the intermittent failures of your tests relying on unstable dependencies.
- t43562 2y agoIf your dependencies are unstable then that is very important to know! If it means you have to add forms of resilience then that's good for your code perhaps?
- bottlepalm 2y agoThe point is it makes you tests nondeterministic which is a huge problem with large fluid teams and thousands of tests. They need to be deterministic.
- t43562 2y agoThat is a fairly good reason for trying to use external systems/tools that make testing easy/cheap to do. So a good approach would be to have tests where you can run with the mock and then run the same tests with the real system. Anything you catch with the mock saves you from using the costly system but you still get real testing.