Unit Tests - Part 1

There’s the thing with Java-style enterprise-y testing. The concept of a “unit test” is utterly and horribly broken. Somehow, over the past quarter century, everything about testing seems to be about mocking frameworks.

It’s bad.

The more you mock things, the more you are testing that the language itself is working and the less you are testing the logic you are writing.

I’ll tell you something: the chance that your code has a bug compared to the chance that the runtime environment has a bug is very, very tilted towards your code and not the runtime.

TDD — Test Driven Development. It’s a common buzzword. It’s how many people think that software should be tested. It’s also completely at odds with the Java-style of testing. There is simply no way that one can know the exact sequence of calls that you’re going to test without having the code you already wrote in front of you. When you write the mocked tests, you are doing little more than restating the logic you’ve already written. You are testing that the language does what it says on the tin. You already wrote the code, you expect it to work, so you write the test to go green.

I prefer a different TDD: Test Driven Design.

With some simple refactoring, you can moving from relying on mocks to test to testing business logic directly. With one TDD, you might even be able to achieve the other TDD. (Not that I think that’s even a good goal) By designing things to be tested, you can (surprisingly?) test the code effectively!