How have you made unit testing more enjoyable? [closed]

Question

If you've always loved unit testing, good for you! But for the unfortunate ones who weren't born with a liking for it, how have you managed to make this task more enjoyable ?

This is not a "what is the right way to unit test" question. I simply want to know little personal tricks that reduce the boredom (dare I say) of writing unit tests.

Answer 1

Firstly, I agree with you - if you are writing your unit tests on already completed code, or you are manually unit testing your code, I find that extremely boring too.

I find there are two ways of unit testing for me that really make it enjoyable:

1. By using Test Driven Development (TDD) - writing the tests first allows me to think about the next piece of functionality or behaviour that I need in my code. I find driving towards my end goal in tiny steps and seeing tangible progress towards that goal every few minutes extremely rewarding and enjoyable.
2. When there are bugs, rather than going straight to the debugger, it's a fun challenge to figure out a way to write a failing unit test that reproduces the bug. It's extremely satisfying to finally figure out the circumstances that make your code fail, then fix it and watch the bar turn green for the new failing test (and stay green for all of your existing tests).

Answer 2

Smug superiority.

I'm only half-joking. "Look at me, cultivating good programming habits! This 'unit testing' stuff is something Me From Ten Years Ago never would have done -- what a fool! And just think of all the bugs I'm going to catch as a result of this boring, tedious work I'm doing right now -- my code will be awesome! I'll get a raise for sure!*"

* -- No, I won't.

I find it's like working out or eating healthy; until the tangible benefits actually kick in ("Holy balls, I really AM catching a crap-ton of regression errors that would have snuck into production!"), the moral pride of knowing that you're doing The Right Thing can help carry you through.

Answer 3

For one, I almost never just sit there and write unit tests. Unit tests are a means to an end, not an end in themselves. They are a way of answering "does this code do the basic task that it is supposed to."

For instance, some people will write a function, and then open an interactive session to test it out on a few values and make sure it's working:

def fact x
  if x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact 10
=> 3628800
>> fact 7
=> 5040

But now you discover a bug:

>> fact -1
SystemStackError: stack level too deep
    from (irb):2:in `fact'
    from (irb):5:in `fact'
    from (irb):10

So you fix it:

def fact x
  if x < 0
    raise "Can't take the factorial of a negative number"
  elsif x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact -1
RuntimeError: Can't take the factorial of a negative number
    from (irb):3:in `fact'
    from (irb):10

But now you really ought to test to make sure it still works:

>> fact 10
=> 3628800
>> fact 7
=> 5040

As you can see, you keep on repeating the same tests... and you have to compare the results visually. Unit testing is a way of avoiding the repetition in this case; it reduces how much work you need to do. And while this is a silly little example, in the real world, it becomes more and more important, and more and more difficult to test manually. What this means, of course, is that people simply don't test the individual components; they just test the whole program. But then bugs crop up, and they're much harder to find. Or bugs happen, and they're fixed, but someone introduces the same bug all over again, because no one added a test case to make sure that didn't happen. Or someone looks at a big piece of code, and says "I have no idea what this is supposed to do, since it's not documented and has no tests... if I fix this bug, I have no idea if I'll break something else depending on it; maybe I'll just rewrite this from scratch."

Unit tests reduce all of the extra work in these cases. The best way to make them fun is to make sure that people understand all of the work that they are replacing, and the extra flexibility that comes from knowing what each piece of code is supposed to do. To some degree, people need to have a bit more experience with writing and maintaining a large code base to understand how important unit testing can be; if all of their code is something they write once and throw away, they'll never quite get it.

And unit tests shouldn't be written after the fact, as an extra chore once you have code that you "know" already works. Unit tests should be written first, or at the very least (since you sometimes forget to write them first) right after writing the code in question. This is called test-driven development, and it can help make your APIs better; if you write the tests that exercise the APIs first, you will learn where the APIs are a pain to use before you even write the code, and can redesign much more easily than if you only add the tests afterwards.

Answer 4

I don't know. What definitely makes unit testing more enjoyable to me is the thought of all the frustrating, lengthy, boring and unrewarding debugging I will not have go through every time I make a change in the software :)

Answer 5

The smug superiority you feel when you check in code that is rock-solid, robust, and stable. And if you write unit tests with a code coverage tool, you can boast in your check in comments that your code coverage is 90% or higher.

Answer 6

Obviously, there is the satisfaction of test-first development and the feeling you get when your design and tests come together. However, writing tests for pre-existing/legacy code can be mind-numbing and frustrating. When our project was in a maintenance pattern, I wrote tests for untested code using the coverage report as a game. You can create a bit of a competition with yourself and/or others to boost the coverage numbers. Granted, you might take it too far and create some bad tests, but it can be a good motivator.

Answer 7

Try to get into the Flow. Set tough, but achievable goals to yourself. What could be a goal in unit testing? For example, try to write faster while keeping quality. Unit tests don't require too much thought so mistaking is unlikely. Concentrate on your goal and check often to see as you are nearing it.

Answer 8

Sometimes to get myself motivated, I'll write down my current "code coverage" at the start of the day. Then each time I write a test and get it to pass, I'll run the suite, and update the coverage number. It's fun, and it helps remind me why I'm doing this. (There are other reasons too, but I like the numbers. Maybe that is just me!)

Answer 9

By not trying to delude myself that I can trick my mind into thinking that unit testing can be enjoyable for any sustainable period of time.

Accepting the reality that unit testing is not there to be enjoyed helps me a great deal, making me realise that I am looking for something in a place where it was never supposed to be.

In these brief mental excursions when I get to the point of perceiving unit testing to be what it really is, i.e. a cruelly, unbearably, and soul-crushingly boring task, I ask myself whether I can afford letting go of them, i.e. not having high guarantees about functional correctness.

Invariably, the answer is a resounding "no".

Upon accepting my fate, I keep pushing these square objects with letters, numbers, and symbols on them in front of me, which we call keyboard, knowing from first hand experience that with each keyboard click, the end of unit testing is closer than it has ever been.