4 ms·
Hey, while we're slaughtering sacred cows, lets kill mocking, endotesting, expectation based testing, and the whole nine yards. It's a horrible practice that ca
by gfodor 15y ago
Hey, while we're slaughtering sacred cows, lets kill mocking, endotesting, expectation based testing, and the whole nine yards. It's a horrible practice that causes you to write too many tests, too many assertions, and results in tests that stay green even if you delete entire files from your codebase.
- 100k 15y agoI would like to keep an open mind about this because I like the theory of decoupling. But the only thing I use mocking/stubbing for is to mock out external services that make tests unreliable and slow (like HTTP requests). Expectation based tests seem particularly easy to mis-use. Who cares how many times a method is called?
- aneth 15y agoHow would you test, say, payment processing, in any sane way, without mocking? How do you test failure handling code when the failure can not be reproduced in a known way by the current code base? I agree these tools are often overused, however they do have their roles.
- gfodor 15y agoYeah I'm not referring to mocking external services, which is both smart and useful. I'm referring to the practice of endotesting whereby you mock your own objects and interfaces as a means to test interactions between them.
- rntrg 15y agoI have found that heavy use of mocking tools couples tests tightly to the design, resulting in great difficulty when I need to redactor. To me, the ideal is that I can change my design as I see fit without difficulty. My tests specify what my application does - how it behaves, not how it is structured. In my experience, this entails minimizing the number of points where tests touch production code, i.e. keeping the test suite DRY. I do use test doubles, including mocks, where things become difficult or slow to test (generally application boundaries). But keep in mind that every line of mocking code costs more than an equivalent line of the alternative.