Photo by Tomek Baginski on Unsplash

——

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!

Kent C. Dodds 🛰️

@kentcdodds

I write tests following TDD when it makes sense

00:28 AM - 27 Jun 2020

16 138

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:

Kent C. Dodds 🪐

@kentcdodds

Please don't take this the wrong way. I do know the difference between BDD and TDD and I've implemented tests in both. I just don't normally think about these methodologies or dogmatically subscribe to them.

01:22 AM - 24 Jun 2020

1 26

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 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! 🙏