Excuses to not write tests

Testing goodness

There are plenty of reasons to write tests; here is a good sum-up.

To me, the most import points are that a good test suit:

• reduces stress
  • you know that at least all the tested features are still working after an update
    • even if that update comes from dummy
  • you’re therefore not afraid to make and accept changes
• helps you writing better code
  • you get a new perspective on the code
  • you can easily refactor

Most importantly, automated tests make coding fun ! In comparison, not having a test suit means that for every single update, you have to think about what might break. In that situation, you become afraid of updating your code and start following this principle: “if something works, don’t change it”. This is how tech debt starts appearing and it will slowly - but surely - grow.

The source of the problem

Testing make coding awesome; unfortunately; it isn’t “mainstream” yet. I myself plead guilty as I professionally wrote applications without any test for a little while - maybe a year or so - shame on me ! The reasons were simple, I wanted to do it but I had short deadlines and it felt too hard and overkilled for the size of the projects I was working on. I was obviously wrong since I’ve found my productivity sky-rocking once I’ve started writing tests.

As far as I know, most junior developers working in small agencies have similar experiences. Even with a good education they know very little about testing and it’s up to them to make the effort. Education is a big issue. Another one in my opinion is a “culture” issue where “testing” is often presented last within the “advanced concepts”. For example, I love Django and the documentation is awesome but let’s have a look at the introduction material: https://docs.djangoproject.com/en/1.9/intro/; there is zero tests there ! Imagine if a beautiful functional test was the first step there. Imagine if a limited set of Python runs in the browser. Imagine there’s no countries…

The problem

Funny enough, if you ask your cowboy friend why he won’t write tests; his answer probably won’t be: I don’t know how to do it, could you help me out? It’s going to be an excuse.

Top 4 excuses

1.“I don’t have time”

“Without automated testing, this project will take me 3 weeks, there is going to be a couple of bugs and I’ll carefully fix them within a day; I’ve always done like this. If I write tests, I’m going to spend 3 weeks and 2 days in total and I’m sure it won’t prevent all bugs. Writing untested code is just faster.”

I used to think like this (see above) and it took me a while before I’ve force myself into learning how to write tests. You could think that a beginner at testing will spend a large amount of time writing tests for little to no added value. He better writes useful code. The wrong assumption here is that writing the useful code takes the same amount of time with or without tests.

In my experience, the time spent writing tests is worth it within a week or two. I don’t have data to back this up, just personal experience.

2.“This is simple”

It doesn’t matter if a project is “simple” or “complicated”; just test it. Simple code should have an equally simple set of tests. In other words, if the code is simple: it’s even easier to test so you have no excuse. Furthermore, we’re less attentive when working on simple code so making errors is more likely.

3.“This is just a prototype”

If that’s really the case, please don’t bother writing tests. In reality, prototypes are often updated multiple times and used as the base of the development once approved. At least, cover your prototypes with some rudimental functional tests.

4.“My minions take care of that”

“As I’m an experienced rock star engineer CTO of space, I design a nice architecture, Joe the intern / junior developer can take care of the “details”; he might write tests if he wants.” I’m not making this up. I’ve heard this (well something similar) ! If you find yourself thinking this, chances are that you are in a position of “power” and you never have to maintain the mess you’re creating; I can’t think of any other explanation. Maintaining your code should be painless; the best way to ensure this is to test it - and maintain it yourself.

In reality

The truth behind these excuses is that our brain is afraid of change/uncertainty and we subconsciously rationalise that fear. We also have excellent reasons to do so: Our work is to deliver working product within a given deadline (usually short). How are we expected to guarantee its delivery if we have to do that thing called “unit testing” on top of our regular work? Especially since we build good quality products already.

To me, the most important factor is that testing (and especially TDD) makes coding a lot easier and more fun. The better quality and reduced number of bugs are side effects of having the best possible support for your code.

Once you go testing, you don’t go back (to manual tests).