Why don’t I unit test?

I few months ago my brother did a couple of tech talk at work introducing TDD and explaining its benefits (and those talks then became posts in this blog). Then a few weeks later we asked our colleagues, if they hadn’t started writing unit test, why was that so.

These are the most common responses to why my colleagues didn’t write tests:

  1. I don’t have time to write tests
  2. I don’t know how to test
  3. I know I should but I’m too lazy

There’s no reason to dismiss any of those reasons and in that meeting we gave each of them a response (the best we could come up with). Following you can find my summary of each response:

I don’t have time to write tests

This one is tough, it would be simple to say that the programmer is lazy and should just do it, but anyone familiar with the workload of programmers and the improvement curve will know what is happening.

We’ll talk about the improvement curve and all its causes in a future episode, but to summarize, every time you try to do something new, like improving on your workflow there will be inefficiencies, this mean that when you adopt a new methodology you will be slower and less productive than you where before. This causes those that don’t expect this to happen to get frustrated and drop the improvement before they start reaping its benefits.

You may hear about TDD and all its benefits, you may hear that it makes you go faster, and since you are overloaded with work you think “Hey I could use that!”. But when you try it and you find out you have to write twice as much code, you drop it in 0.2 seconds (then you write a blog post about why TDD is dead or why it doesn’t work for you).

To fix this you have to attack the root cause, the programmer is overloaded and has no time to sharpen the saw, an organization that wants his developers to practice TDD has to invest in this improvement curve, and reduce the workload till they learn this new methodology, only then they will be able to be more productive (that’s why it’s called investment! you get disproportionate results but it takes some upfront costs).

If the company doesn’t want to invest in this and the programmer is determined to improve his abilities then he’s the one that needs to make and investment, going the extra mile out of work till he can go back to being productive. I know, I know, this isn’t right, is the company that will reap most of the benefits so they should be investing, but this is the real world and we can’t always wait for the rest of the world to act rational and do the right thing. If the company won’t do it, you can improve on you own.

I don’t know how to test

This is similar to the previous reason, in that it takes concerned effort on your part to overcome. Finding out what does it mean to TDD is easy. Setting up your environment to test takes about 10 minutes, and you can watch a couple of videos introducing unit test, but then you have to actually write your tests.

We already went in great depth into the process but the gist of it is that you should write the test that forces you to write the code you wanted to write anyway. (you can re-read that, I’ll wait)

After that, you should write test that explore the boundaries of your problem (like passing a null, or an empty list).

Then you can continue with some simple cases and grow from there.

This is how you start, but you need to realize that you will be a noob TDDer. How much have you been programming (5 years? 15 years? more?), how much have you been TDDing? 5 minutes? 15 days?

Your first test will suck. They will be hard to follow, slow, break a lot and be full of duplication. Every time you change something you will need to fix most of them.

But this is not how TDD works in the real world, you shouldn’t give up on it just because you suck at it. It’s like changing your keyboard layout from QWERTY to DVORAK, even tough you know how to program and you know what keys you want to type, you will be slow and make a lot of mistakes, but then you will get used to it. You will learn new techniques, you will write better test, cleaner test. Only at this point unit tests will be a net positive gain for you, and once you reach this point, there’s no going back.

I know I should try but I’m too lazy

I’m not making this up, this is a real reason I was given for not writing unit test. The problem with this reason is that it is not the real one. This programmer most likely isn’t lazy, the problem is that he feels overwhelmed by the amount of work that it will mean to go full TDD, so he keeps procrastinating.

We saw in the two previous section that TDDing is simple but not easy. Specially if you are working in a legacy code base, it will be an uphill battle.

The only advise I can give you is this:

Start somewhere, do a small step and then keep improving.

Not every project is perfect for starting with TDD, not every CR is perfect for starting with TDD, but some of them are and of them most are Just OK.

You need to start somewhere, first setup your environment and do a couple of tutorials. Then choose a project where you tend to have CRs that add functionality (instead of changing existing stuff). Now setup a test project in that solution and then write a small unit test for a small piece of functionality. No need to TDD it, no need to do all of it. Just start somewhere and then… never stop improving.

Now is your turn

If you want to keep updated please subscribe.

Author: Maurizio Pozzobon

Maurizio has 5+ years developing solutions in the insurance industry. He is passionate about doing the right thing right, so he works in a tight loop with his clients to deliver the best solution possible.