Hacker News Reader

Comment by jcpst | Hacker News Reader

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.

View on HN

If 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.

Yes 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?"

When code is written to interfaces those interfaces can be mocked without mocking frameworks. Mocking frameworks mask poorly structured code.

Then 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.

You just rephrased "issues in a code base's architecture" as "mask poorly structured code" without saying how.

Reply on news.ycombinator.com