3 ms·
This perspective is really interesting to me. I’d be interested in knowing what people find problematic with it. I used to unit test all the components individ
by jcpst 3y ago
This perspective is really interesting to me. I’d be interested in knowing what people find problematic with it.
I used to unit test all the components individually. But these days I test with most of the componentry wired up, only mocking the i/o layers. I end up writing fewer tests, they have been less brittle, and refactoring is easier.
- 0x445442 3y agoIf you want to expose issues in a code base’s architecture, don’t allow mocking frameworks and see how complex and lengthy unit tests become.
- pc86 3y agoYes if you eliminate an entire class of testing infrastructure, tests become harder to write because you end up poorly implementing that infrastructure in every class. How does this show you "issues in the code base's architecture?"
- 0x445442 3y agoWhen code is written to interfaces those interfaces can be mocked without mocking frameworks. Mocking frameworks mask poorly structured code.
- piva00 3y agoThen you have to reimplement method call count when you need to assert something was called in your interface-based mock; and reimplement differing returns based on input or call count; and maybe reimplement throwing exceptions when those are necessary to test not-so-happy paths. In the end you'll have an implementation of the interface with quite complex logic in the methods' implementation to handle differing returns, which will couple your mock implementation to the test cases setup, or you'll reimplement a mocking framework. I prefer to use a mocking framework to deliver stuff instead of stabbing myself to keep purity of interface-based APIs.
- pc86 3y agoYou just rephrased "issues in a code base's architecture" as "mask poorly structured code" without saying how.