4 ms·
Any yet it's extremely valuable when you want to test code that deals with externalities (aka, i don't need to actually insert a row into a db over the wire to
by awinder 10y ago
Any yet it's extremely valuable when you want to test code that deals with externalities (aka, i don't need to actually insert a row into a db over the wire to make sure my biz logic works, and in some cases like error handling testing, it'd be way harder to actually code the situation rather than to simulate it), and tends to give you a baseline set of reassurance that can run very quickly. So IDK about just hauling off and labeling it as "moronic".
- goldenkek 10y agochecking for an insert into the database in the most general fashion is okay. checking for the exact dynamic data?? you are basically copying your code.
- awinder 10y agoI'm just saying I can cut test time dramatically by not testing that X db actually can do it's job in expected ways, and those tests can run sans networking and unexpected situations won't cause false negatives. Both things are fine and they go very well together but each allows you to do different things
- goldenkek 10y agoexact tests on implementation at the "db was updated properly" category are usually classified as integration tests. theres nothing wrong with those. but one shouldnt test specificity of internal method code for small units.