Click anywhere to close
Free Xbox One + FIFA 15 Bundle

“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

24th May 2012 by

8 thoughts on “The Logic of Testing and the Testing of Logic”

  1. Comment by Ric Roberts

    24th May 2012

    The choice of new Spock over old Spock is illogical.

  2. Comment by Mark Stickley

    24th May 2012

    Nothing wrong with gutter rails. Some people see it as cheating, some people think it defeats the point but if your goal is to knock down pins there's no denying that the rails increase the odds, particularly if you're not a strong bowler. Of course if you are a strong bowler you should be able to get that strike without even touching the rails. But it's nice that they're there, you know, just in case. You can't rely on the rails to guarantee a strike. You might not even hit a single pin depending on the angle the ball approaches or how far back your gutter rails extend but there's no denying they help a lot. Did I stretch that analogy too thin?

  3. Comment by Sean Handley

    24th May 2012

    You can never stretch an analogy too thinly ;-)

  4. Comment by M1ke

    24th May 2012

    Very true, and don't worry about the confessional, I did pretty much the same thing over on my blog yesterday (http://m1ke.me/blog/find-failure-faster). It's also useful to point out that your tests can still fail to fully encompass your business logic, so always make sure that there are obvious ways for you to find out quickly when a use case isn't accounted for. If people don't want to use tests that's their choice, we'll just produce better code and make more money!

  5. Comment by Gemma Cameron

    24th May 2012

    Living documentation?! That's crazy talk.

  6. Comment by Andy Gimblett

    24th May 2012

    Next step: encoding your business logic in your type system. :-)

  7. Comment by robinr

    24th May 2012

    "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." quote of the decade

  8. Comment by Sean Handley

    24th May 2012

    Not saying they don't happen. But on average I spend a lot less hours these days putting out fires than I used to and I get a similar impression from many others in the dev community.

Leave a Reply

Your email address will not be published. Required fields are marked *