When does TDD make sense?
Tags: testing, react, javascript
Published: 2020-06-29 12:43:15

---
title: When does TDD make sense?
published: true
description: If you need to ask this question, then TDD makes sense.
tags: testing, react, javascript
//cover_image: https://direct_url_to_image.jpg
---

Over the weekend, I noticed this tweet appear in my timeline:

{% twitter 1276673772251017216 %}

A bunch of people replied to this tweet asking: **_Great! But... when does TDD make sense?_**

Especially on the front-end, this question comes up a whole lot. Front-end programming has a legacy of being unsuited for TDD.

With that in mind, here’s a simple set of guidelines that I use to help answer this question.

| If... | Then...|
| -- | -- |
| You’re unsure if TDD makes sense | Use TDD if you can (see below for why) |
| You’re working on a team | Use TDD |
| You’re writing static pages without behavior, like a marketing site | Don’t use TDD |
| Getting to market **fast** is more important than quality or maintainability | Don’t use TDD |
| You’re unsure of what you’re building | Spike first, then test later |
| You’re working alone on an unreleased project | Don’t use TDD |
| You’re working alone on a released project with users | Use TDD |

Interested in why I arrived at these conclusions? Read on.

###You’re unsure if TDD makes sense

With enough experience of TDD, you will understand when to apply TDD and when not.

**So if you need to ask the question “When does TDD make sense?”, then TDD makes sense.**

You need more experience. You need to get more practice.


Practice doesn’t necessarily mean building toy programs. Instead, find opportunities in your daily work to try TDD.

**Finding ways to shoe horn TDD into your daily work practice is a whole topic itself**, so, for now, I’ll suggest just this:

_Start small._ Next time you’ve got to add a new component to your React app, try doing it with TDD.
 
###If you’re working on a team

TDD is a structure that helps you articulate and outwardly express ideas that would otherwise be locked in your head.

That makes it **a great socializing tool for getting feedback early on your designs.**

TDD goes hand-in-hand with pair programming (when you work with someone else) and team programming (sometimes called mob programming, which is when an entire team works together in front of one screen and one keyboard).

TDD can also give a speed boost to teams.

**Ever experienced how slow the code review process can be?**

You wait patiently for feedback and then, when it arrives, you context switch back to make the suggested changes. Then you repeat the cycle. This takes a whole lot of time and it’s mentally (and emotionally!) draining.

When you apply TDD with others, you pull that feedback process forward, which saves time later on.


###If you’re writing static pages without behavior, like a marketing site

TDD is about testing behavior. Your marketing site does not have behavior.

Sure, you might want to add acceptance tests for this code, but that’s a different part of your development process.

###If getting to market **fast** is more important than quality or maintainability

If you think following TDD will slow you down, and that in turn will lose you money and market share, then don’t use TDD. You can always come back to add tests later.

###If you’re unsure of what you’re building

To “spike” is to _write code without tests_. Often you do this when you’re exploring a new technical domain for the first time. Spike until the point that you’re confident of the shape of your code. Then you can start adding tests.

###You’re working alone on an unreleased project

If you’re building a side project that doesn’t have any users yet, and may not ever have any, then I’d avoid using TDD unless you’re specifically aiming to get better at TDD.

This can be argued two ways. On one hand you could say that TDD will delay finishing, and that translates into a risk that you will never finish.

On the other hand, you could say that without TDD you’ll end up with low quality software that risks never attaining any users because of the poor quality.

Of course, there are other ways to have a poor quality product other than simply having buggy software. You could build the wrong thing entirely: in other words, something that no one wants to use.

So for me at least, the scales tip in favor of not using TDD. Instead, you should focus on getting a finished first version ready.

**However** if you’re absolutely sure that your project will one day have users, and the use cases and requirements are clear, then start with TDD. It’ll save you time later on.

###You’re working alone on a released project with users

The moment your side project starts attracting users, then you want to start using TDD in order to save yourself from nasty regressions.

---

I’d love to hear feedback if you agree, disagree, or if this was in any way useful. Go ahead and leave a comment below.

Happy coding! 🙏