Engineers learn about test-driven development in college classes or bootcamps. One of our developers recently told me he learned TDD was a “best practice, but no one actually does it.”
Basically, he learned it was a good thing to talk about in a job interview. Outside of that, it probably wouldn’t be something he had to do.
Before we dive into why this is, let’s have a brief definition of TDD
. Generally, it means is you write tests before you write code.
Your test says something like: “I expect a user to be able to log in using Google.”
At first it fails, because the application only lets people log in with their own username and password. Then, you write the code to allow users to log in with Google. All of a sudden, your test passes. Tada! That’s TDD.
The beauty of TDD is that it focuses your work. You know exactly how you want the code to perform, and then you get it to do that thing.
Test-driven development also ensures that if someone unwittingly removes a line of code and breaks the Google login, the test fails. Everyone knows immediately what went awry.
Testing this way helps maintain consistency. It also prevents anyone from introducing new bugs that break existing functionality.
Our new hire was surprised that we actually practice TDD at Radial. Even though it has all these advantages, it is often overlooked.
Often, non-technical project managers see TDD as a time sink. It does take time. It also means businesses and developers have to prioritize what is important to test, and what isn’t worth it.
As any engineer who has pulled an all-nighter hunting a regression bug will attest: TDD saves time in the long run. But many engineering cultures focus primarily on short-term results and discount these longer term costs.
Whether it is 3 months or 3 years later, a lack of quality testing will drag your project down eventually. The question is, do you want to pay the cost incrementally up front, or in large chunks later on? It’s worth thinking about.