Hacker News Reader

Comment by tunesmith | Hacker News Reader

The biggest missing element, in my mind, of the pro-"classicist" and anti-"mockist" view is that the practice of writing unit tests with mocking leads to refactoring your code until it works with that approach, which in turn leads to better-designed code. I don't like the emphasis of "yeah but refactoring code leads to needing to rewrite mocked tests", because if you've designed your code well, then the need to adjust an api boundary should be less frequent than the need to adjust the internal implementation details. Focusing on integration tests means you can get away with poorly designed code full of corner cases that your integration tests can't catch. Besides, "we can keep the fast feedback loop with parallel tests" really increases the demands on complicated tooling that breaks often.

View on HN

You can only get away with poorly designed code if that's not caught in the code review. I'd argue that while that might be a nice side benefit of some testing practices, forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals!

(Also, you can easily run integration tests in parallel with a little planning and attention to detail. For example, if your IDs don't rely on a sequence (like UUIDs), you can generally run them in parallel regardless of database connections.)

> forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals!

Are you avoiding rewriting your code so you can write integration tests, or are you writing integration tests so you can avoid rewriting your code?

Those that have been around the block of refactoring code so you can write good unit tests, tend to realize that the better-designed code isn't a side benefit. It's the entire point. The test is the side benefit.

Integration tests should be avoided if the same coverage can be reached with a refactor and some unit tests. For instance, it's very common for components to rely on complicated combinations of state. For instance, imagine a nightmare component that has nine boolean state parameters. To integration-test every combination, that's 512 cases. But in cases like those, you might discover through refactoring that some of those state combinations can compressed. For instance, you might be able to refactor into three sub-components, each of which take three boolean parameters and return one boolean result, and where the parent component only depends on those three booleans, which can be mocked. So then in that case, you've reduced the amount of tests you need to write to 32 total... that's 1/16th the effort.

I mean, I know that in common practice, neither are done, and people just leave the component largely untested, and then get bug reports that they close as "Can't reproduce".

Thanks for the heads up. It’s 10 years old, but I hadn’t seen “Mockists Are Dead. Long Live Classicists.” before (https://www.thoughtworks.com/insights/blog/mockists-are-dead...).

The Classicist point of view resonates strongly with me - I’ve long considered mocking in tests to be a code smell, and only usually justified for stubbing external services or hardware.

Reply on news.ycombinator.com