React developers: TDD is not dogma
Tags: javascript, testing, react
Published: 2020-06-26 10:55:19

---
title: React developers: TDD is not dogma
published: true
description: TDD is a process that gives you space to think
tags: javascript, testing, react
cover_image: https://source.unsplash.com/14ocb5uMI1Y/1000x420
---

_Photo by [Tomek Baginski on Unsplash](https://unsplash.com/photos/14ocb5uMI1Y)_

——

_**Update**: Kent replied to this article and was kind enough to explicitly tweet the following about TDD, which then provoked a great discussion from his followers. Thank you Kent!_

{% twitter 1276673772251017216 %}


_The original article is below._

——

A couple of days ago, React’s leading educator on testing wrote a tweet about **test-driven development (TDD)** that displayed a common misunderstanding:

{% twitter 1275600046508007424 %}

This is a back-handed compliment that relies on the belief that **TDD is dogma** (and if you read the parent tweets, also on the belief that using TDD/BDD doesn’t result in valuable tests).

I’m highlighting this because I worry that a whole generation of programmers will miss out on learning a valuable skill because of the strong words from their respected peers.

I worry that people will read this and think “Kent doesn’t use TDD, therefore TDD must be bad.”

It is also a risk to the ongoing adoption of React if the community fails to embrace an important industry technique.

Personally speaking, **using TDD gave me a huge boost in my career as a software developer.** Without TDD I wouldn’t be a successful independent consultant. It has helped me write high-quality Windows desktop applications in C#. It has helped me build backend monoliths and microservices in Ruby, Java and Clojure. And of course, I’ve also used it with success on the frontend: not just with React but other frameworks, with vanilla JavaScript, and with ClojureScript too.

##TDD is here to stay

TDD has been around **for decades** and is a natural progression for developers who are interested in testing. 

When you start writing tests for the first time, you are bound to make mistakes. The more mistakes you make, the more you learn about “good” testing practice. Eventually you learn about TDD, and suddenly you become slightly embarrassed about everything you did before.

##TDD is anti-dogma

The TDD process is _not_ dogma. In fact, learning to _cheat_ at TDD is part of the fun of TDD. (But you can’t cheat until you’ve practiced the game so much that you know the rules by heart.)

**TDD is _disciplined_.** TDD says that every single line of code your write must be written with thought and care.

The reason that TDD is anti-dogma is that **if you apply TDD, then you can write your code whichever way you like. Nothing is out of bounds.** As long as the tests pass, you’re good.

And if the tests are passing, you’re free to refactor your code however you like.

##TDD is social

TDD, combined with pair and team programming, offers a process that allows teams to combat some nefarious team problems: siloed development and overly-complex code are two that spring to mind.

TDD helps a team perform at a consistent rate. In agile parlance, people talk about consistent velocity being a sign of a high-performing team, and that’s what TDD helps teams achieve.

##TDD is for beginners, too

There are coding bootcamps--like [Makers](https://makers.tech) in London--that teach TDD to new recruits. Group learning combined with tuition from experts is a fabulous way to learn TDD. And developers who graduate from TDD bootcamps are highly sought after because of their skillset.

##Our community is full of dogma. Be careful!

The React testing community is actually very fond of dogma: _Stop mocking fetch! Don’t use nested describe blocks!_

To be clear, **this is what dogma looks like**.

One trick that has kept me well informed over the years is remembering that **anytime someone tells you categorically not to do something, they are stating an opinion based on their lived experience, not fact.**

Unfortunately in computing, it’s very common to see developers conflate something that is valid for their lived experience with what is valid for everyone. _“This didn’t work for me, therefore it can’t work for anyone!”_

The best we can do as teachers is to say: **“Here is something that works for me, and here’s how I like to do it.”**

##I’m not asking you to use TDD

Remember that in the grand scheme of things, the React community is still an infant. It’s still learning about the world. It has much to learn from the rest of the industry.

I’m not asking you to use TDD. **I’m asking you to keep an open mind.**

Happy coding! 🙏