A Philosophy of Testing 3: The Problem of Unit Tests

A Little History

In the Beginning, (that is, pre-2000), automated testing mostly wasn’t a thing. A few companies did it, and everyone agreed that it would be a lovely idea if only it was feasible, but most folks didn’t take it seriously. I’m not sure that I encountered any serious automated testing in my career up to 2001.

Unit Testing in Scala Services is Mostly a Waste of Time

Most individual Scala classes do not require deep unit testing in and of themselves. They shouldn’t usually be mutable, so you don’t have as much of the state-machine problem. They should be strongly-typed, and generally null-free, so most illegal-argument tests are unnecessary. (Indeed, many of them wouldn't even be compileable.)

The Problem of Mocks

Let’s drive this home more: in Scala services, an excessive focus on unit tests is actively bad for your project. Why? Well, let’s think about what a unit test looks like in a plumbing-centric environment.

The Problem of Coverage

Just to add a kicker: excessive unit tests get in the way of proper code coverage.


The above is pretty strong stuff, and I’m sure that some folks will disagree. That’s fine, but please think about it seriously. I’ve found that an excessive reliance on mock-centric unit tests generally does more harm than good when working on Scala services. And it’s unnecessary: I pretty much never use mocks for my Scala tests, and I’ve never missed them. There are better alternatives.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mark "Justin" Waks

Mark "Justin" Waks

Lifelong programmer and software architect, specializing in online social tools and (nowadays) Scala. Architect of Querki (“leading the small data revolution”).