The Logic of Testing and the Testing of Logic

24 May 2012 | by Sean Handley

"Business logic is slippery and changing (if it isn't, you're not in a business that will ever make any money)"

This feels like a confessional: I only started writing automated tests for my code about a year ago. I'd known about the frameworks, the concepts of TDD/BDD etc for many years but it took a good 5 years for me to really appreciate the value. And now I see it, I don't understand why anybody could assert that writing tests is a bad idea.

Sure, if you do it badly, or write meaningless tests, or spend too long doing it, then you could view it to be a bad thing. But that doesn't mean "testing is bad", it just means "you're doing it wrong".

But these people are still out there. Like the flat earth society, flying stubbornly in the face of reason. I've even heard it said that "tests are gutter rails for bad developers". I don't know how I feel about the bowling analogy but I've yet to meet a player who never misses a strike or never slips and gets a gutter ball.

I have to say, the developer ecosystem in a community/support sense has vastly improved in the last 5 years through github, stack overflow, etc. So support, documentation, answers, examples are replete. And coding standards are a lot higher as a result because people are steered away easily from the gotchas and quickly rescued from those that slip the net. Also, languages are a lot more forgiving than in the bad old days. It's pretty rare to hit a truly catastrophic bug that costs money in production.

But nobody can ever save you from yourself and your own ignorance of your problem domain and the subtle, dark corners of your business logic. That's the key, in my mind. The common issues in serving pages, rendering data, authenticating users, interacting with persistence layers etc are well understood and tested with well-made wheels that don't need remaking. But your business logic is slippery and changing (if it isn't, you're not in a business that will ever make any money) and the only person on the whole Internet who can help you with it is you.

Are you that good to get it right the first time?

The answer to that rhetorical challenge, naturally, is yes. But not all in one go. Small steps, short iterations, exploratory ideas, working through the problem space piece-by-piece with careful thought. And documenting as you go. A test is an executable scratch pad, a living white board of ideas expressed in code that can be re-used.

And if your business logic changes, so do your tests. And that's a good thing. Because if you don't quite know what your business logic is any more, then you don't quite understand how your software is going to help the company make money. As a developer, a manager, or a CEO, I wouldn't ever feel comfortable with that disconnect.

So, skip all your boilerplate framework tests if you like - if you don't feel like you need them, you probably don't. But please, please lock down your business logic in tests. Maintain them. They're a working representation of what's actually important.

Sean Handley, Developer and Cookiemonster @ Melbourne

Like what you've read?