Building a testing habit that sticks

Photo by rawpixel on Unsplash

I’m fascinated by the concept of habits, which the Oxford dictionary defines as:

A settled or regular tendency or practice, especially one that is hard to give up.

The reason for habits is one that has to do with our ability to process information. When we find ourselves with a new problem, it takes us mental effort to come up with a solution to it.

Once we have seen a problem repeat itself and we found a satisfactory way to deal with it, the brain starts to automate it so the reaction doesn’t require conscious effort.

This automated behaviour means we can react to particular situations much quicker and with seemingly no effort, and free our consciousness to deal with new problems. Here is where the power (and danger) of habits lie.

The mechanics of how habits work is usually referred to as the “habit loop” can be characterized by a sequence composed of four parts:

1. Cue: an event, time, place or thought that triggers the habit
2. Craving: how we interpret the cue, what are we trying to solve
3. Routine: the actions we take to achieve an outcome
4. Reward: what we gain from having performed the routine

Let’s look at a few examples:

1. Go into a room and notice that it’s dark inside (cue)
2. You want to see to find those keys (craving)
3. Find the switch and turn the light on (routine)
4. Move inside the room and find the keys (reward)

We associate being in a dark room with turning the lights on. Now one that my parents particularly encouraged:

1. Turned on the lights and finally found the keys
2. Nobody else is inside and I should not waste money
3. Turn off the lights as I leave the room
4. Helping maintain a low energy bill

This time the association is when we leave a room and the lights are on, switch them off as you go out if no one is inside.

Why building a habit of testing

As I mentioned previously, solving a problem requires conscious effort, and habits are a way to automate that effort and free up our brain to solve new problems.

So think about this for a moment, which problem deserves the most of your conscious mind:

1. Figuring out if your code is still working as expected?
2. Implementing that checkout flow to allow your business to make money?

If you think 2. is the answer, then creating a testing habit is the way to go.

Structuring the habit of testing

We need to go back and look into the habit loop to understand what are the components of it and how that fits in our daily work. There will be a cue, craving, routine and reward.

In most software companies there will be some kind of repository of work to be done, with tasks ready to be picked up. Our cue to the habit could be to assign one of the tasks to yourself.

The craving is to ensure the new feature work as expected and not worrying about breaking others.

A routine would be following Test Driven Development practices like Red-Green-Refactor, which in themselves consist of habit loops (it’s habits all the way!):

1. write a test and see it fail
2. to be sure that all functionality works as expected
3. write enough code to make it pass
4. the feeling of achievement and making progress

The reward is a high degree of confidence we have a working feature. Not only that, but we also know that we haven’t broken others functionality.

So far this looks simple, right? You start with a sea of red capital Fs:

Ruby rspec test failing

And then slowly turn into a neat orderly line of green dots:

Ruby rspec test passing

Or a flying colorful Nyan cat:

Credits to mattsears/nyan-cat-formatter

The powerful aspect about this practice is that it combines two things our brains crave:

• quick feedback
• the feeling of success (and progress)

Now picture a person going through these cycles over and over again every few minutes and after a few hours find itself feeling like he/she has achieved something great and higher confidence that the code works.

I think we can all agree that those days are awesome days. But then if this is so great, why not all the code we work on has tests?

Making it stick

The most common problem I found to make the habit stick is that testing is a new skill and has a learning curve.

The approach I’ve seen works best has been pair programming. It helps to make that ramp-up on testing smoother by having a more experienced person “navigate” and avoid the initial frustration.

Remember we want to create a craving for the reward, but that won’t happen if the reward is not appealing.

Another key point to why testing won't stick is very simple: Speed.

Pause for a minute and see how it feels to wait 60 seconds:

How are you feeling? Energized and super eager to keep on reading? Or a bit anxious and wanting to leave right now?

This is what we feel when trying to run tests takes 60 seconds, hardly something that leaves a nice impression. What if running tests take 3 hours?

In this case, the options I found so far are:

• You don’t need to run all your tests locally, but make sure that it’s possible to run a small subset in less than 60 seconds.
• Throw some money at the problem and parallelize your tests. Having to wait 3 hours to know if all the test pass is not ok. Bringing that down to 10 minutes makes a huge difference.

Wrap up

I do think that the skill of building habits is very useful and can be applied to many different things in life and work. It takes time, requires experimenting with different approaches and learning what works for you.

I am convinced that both us and the codebases we work on can be improved by tiny consistent incremental changes. Finding better strategies that are in sync with how our brain work feels like the “path of least resistance”: why fight your brain when you can work with it.

If you are now intrigued about habits and want to learn more, I would recommend The Power of Habit by Charles Duhigg, Atomic Habits by James Clear and “Tiny Habits” by BJ Fogg.