It only 'makes sense' on a theoretical basis. On a practical basis, unit testing tons of static methods is a nightmare.

I find it pretty easy to test static methods. To me, testing a ton of static methods would seem a bit easier than testing a ton of classes, since static methods are usually stateless and so require less setup/cleanup work.

Could you explain a bit more about what makes static methods harder?

Static methods can be easy to test, if they are zero or near-zero dependency. e.g. Math.log(x) is easy to test.

However, a static method that accesses other layers is often very hard to test (at least in isolation). For example if you have a static controller method that accesses some service layer you would normally want to mock that service layer for testing so you can test the controller code in isolation.

If the method is non-static and that service layer object is a class member, it is very easy to replace your production service layer with a mock (using dependency injection or mockito, etc).

However if your controller is static, it can only access static members of its class or instantiate the service object with a 'new' operator. Either way there isn't a 'seam' in the code where something like dependency injection or mockito can intercept your app's wiring to replace the service object with a mocked version.

Worth noting I'm coming from the Java side of things here, perhaps Scala is built in such a way that 'new' and 'static' type things are interceptable in a way that allows mocking.

In our Play app, we isolate the real tricky stuff from our controllers and then write unit tests for it there. The controllers themselves end up being fairly lean and simple, so we test them (along with the front-end) with Selenium. We're not dogmatic about 100% coverage as we are a start-up trying to move fast, but this approach has worked well for us.