3 ms·
You should never mock anything. Test against the same dependencies that exist in production. If that's impossible (i.e. you get charged for the backends or you
by devit 6y ago
You should never mock anything. Test against the same dependencies that exist in production.
If that's impossible (i.e. you get charged for the backends or you are controlling physical objects), then generalize the program to support alternative backends and frequently test only those that can work in the test environment, using some more ad-hoc methodologies for the others.
Also, in general, if you need to change your tests for valid changes in the implementation, then your approach to testing is completely broken. An example are dumb testing strategies where you check that the code produces specific SQL queries instead of checking that the code returns correct results.
- doublesCs 6y ago> Test against the same dependencies that exist in production. Interesting. I said this at my work recently and I got a condescending explanation about how production things are production, we don't touch them. If we need stuff for development, those are dev things. I now think that whether this is or isn't a good idea depends on specifics. Most often than not, I think it makes sense.
- detaro 6y agoI think parent means test against the same code, not against the same instance as production. Tests don't get to talk to the production database, but should use the same database software, deployed as similarly as possible, as production does. Against test/demo versions of APIs if possible. ...
- tmountain 6y agoWith an identical schema to boot.
- tyurok 6y agoThat's where "works on my machine" comes from. The further you steer dev environments from production, the more you'll have these kinds of issues. Would you mind expanding on their explanation? The way you described doesn't sound like an argument at all.
- devit 6y agoI don't mean testing against the production instance, but rather against an instance configured like the production instance, except for being scaled/sized appropriately for the testing data and workload instead of the production one. It's also possible to test against live production instances and data itself (mostly useful for performance optimization work and testing), although that's more of an ad-hoc process and some kinds of tests are not possible because the actual data there is arbitrary. Also, those tests, if not used for development, might be better expressed as self-checks done on system start and monitoring systems.
- steerablesafe 6y ago> Also, in general, if you need to change your tests for valid changes in the implementation, then your approach to testing is completely broken. An example are dumb testing strategies where you check that the code produces specific SQL queries instead of checking that the code returns correct results. I don't see how this relates to mocking at all. You can write good or bad tests this way regardless of mocking.