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!
I write tests following TDD when it makes sense00: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:
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
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! 🙏
Top comments (9)
Great article!!
I am an experienced developer, but sadly testing has been a place where all my professional projects have been an afterthought because there is always a QA person dedicated to writing tests. Do you have any sugestion on some resources on TDD.
Kent Beck’s books are a great starting point. What language(s) do you work with?
JavaScript mostly, and right now I have been working on React to fully Master
You can always check out my own book for learning React TDD (see my bio for info). Another amazing book that helps with getting the same mindset is 99 Bottles of OOP by Sandi Metz--I’d recommend reading that for sure.
"anytime someone tells you categorically not to do something, they are stating an opinion based on their lived experience, not fact"
That's not what Kent did, so I'm not sure why this article was written. People should use whatever methodologies are best for them individually. Try TDD by all means. But the claims you write better code/are a better developer because of it are to quote an article I just read: "an opinion based on their lived experience, not fact"
Thanks for taking the time to comment.
You are correct on the last part. Almost everything you read about in programming is an opinion. I am glad that you took that last quote to heart, it’s a key point. ❤️
The first statement you mentioned was a comment about that tweet but about other things Kent has written, for example recently he told people to avoid mocking fetch and use a fake object library instead. Mocking fetch is a perfectly valid testing technique that I and many other coaches have been teaching for years, so when Kent writes an article about his lived experience as if it were fact, it takes a lot of extra work to undo that message, because the people we’re coaching get confused about who to listen to and who’s “right”. Obviously there’s no right (see above) but it takes time and energy to have that discussion, which gets tiring when it happens again and again.
That’s why this article was written.
Great article!
By the way: there are many areas in software development which still in their infantry. For example bare metal embedded apps often look like they were written 30-35 years ago.
Great point. I don’t know anything about embedded apps but I’m guessing it’s a lot of C?
Usually yes, but recently there started to be visible significant rise of use of C++, especially templates. Testing is still sparse at best, although book Test Driven Development for Embedded C is almost 10 years old. Overall software development is very conservative in some aspects, especially in adoption of new techniques and practices.