Daniel Irvine đłď¸âđOver the weekend, I noticed this tweet appear in my timeline:
I write tests following TDD when it makes sense00:28 AM - 27 Jun 2020
16
138
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! đ
