The Most Common Mistakes in Test-Driven Development
Photo by JESHOOTS.COM on Unsplash
Test-driven development (TDD) is a simple practice that can lead to fewer defects in code.
According to this study, there is one common problem — developers do not always apply all of the steps correctly.
I’m going to use this article to explore the findings of that study and what we can learn.
The Mistakes Developers Make in TDD
TDD is theoretically a simple technique with only a few steps to be followed. As we all know programmers are not perhaps as disciplined as they should be which can lead to poor-quality code and/or unexpected behaviors.
Here are the common mistakes in TDD (in order):
Failure to watch the test fail
Programmers feel this is an unnecessary step in TDD since they just wrote the test and know it’s expected to fail. However, when coders skip this step, they make a mistake if that new test does not fail. This can lead to ‘false positive’ tests of code and ultimately failing code passing into production.
Nearly 25% of programmers forget to watch the test failing which in itself is a failure.
” Fail by not failing? Amazing”
Skip the refactoring
Once the code is working TDD states that the programmer should refactor to create clean code. About 1% of coders always forget this step and I assume pass rubbish code into production.
”Refactoring is the fun bit of coding”
Refactor another piece of code while working on a test
When you’re working on a piece of code you might see some other legacy code that needs fixing. TDD states that if there is a failing test you need to make it pass and only refactor when you have green.
Almost 40% of programmers make this mistake regularly and probably costs them a great deal of time in the process.
”Don’t do two things at once. KISS”
Use bad test names
Programmers spend more time reading code than writing code. It’s a good idea to take time to think of good names before implementing a feature. If the test name is good programmers will save time understanding what the code is intended to test which is a great thing.
”Naming is one of the easiest things in computer science. Is that correct?”
Failure to start from the simplest tests
The best way to test is from the simplest case. Not only is this an ego boost for the coder (seriously) but means that you start getting the work done as fast as possible.
”Do the easy bit first”
Run only the current failing test
I’m sure you recognize that you should be running all of the test suites to make sure you haven’t broken anything when fixing your current test case. Keep making sure that you haven’t broken the existing code and you’re probably going to be able to make progress.
”Don’t break it. Just don’t break it. Ok?”
Failing to understand complex test cases indicates a problem
I’ve noticed in my current employment that people are not writing tests if the case is too difficult.
I need to remember that there is an outcome for this.
”If refactoring code is fun, refactoring test code should be more fun”
Failure to refactor test code
If you’re able to refactor code you’re able to refactor test code. Remember that tests should not have repeated code either.
”Just make your code cool”
Implement properly
35% of junior coders will implement the minimum to get a test to pass. It’s not good and if you are implementing TDD this needs to stop.
”Great. Blame juniors again. That makes sense”
What we can learn
It’s really important to understand that this article is about TDD, but the learnings aren’t.
Here are the most important things that we should take away from the study in question:
Discipline in programming is important
Refactoring makes things better
Testing is of utmost importance
Bear that in mind when you pull that next ticket from the backlog.
The actual thing most forgotten in TDD
I’m amazed this has to be said, but there is one thing more frequently forgotten than anything above.
It’s to practice TDD.
“Zing”
Conclusion
Mistakes in the TDD process contribute to poor quality and coding defect rates. If you’re going to adopt a process it pays to understand it and get it right.
Even better is a process that encourages you to refactor and innovate your code.
”Perhaps we should get rid of coders who are not interested in coding and refactoring. Just a thought”