Using test-driven development (TDD), fully or partially, improves your coding speed and can give you the confidence to make changes to not only your own code but other software engineers’ code as well. This increases your delivery speed, which is what matters to release a product on time and on budget.
The most common reason I’ve found for why people don’t use TDD — even when they want to — is that they are working on legacy projects. While it may seem too difficult to accomplish on projects like these, there are some easy steps that you can follow to make TDD work for you.
Top Tips for Getting Started with Test-Driven Development
As a general rule, never begin TDD when you have a tight deadline, and always try to do it with guidance from someone with experience in this methodology.
1. Start with API Requests
My recommended way to start with TDD is through API requests, as they usually are isolated or are relatively easy to isolate. If you are going to do a new API request or you need to do a change to an existing one, it’s a great opportunity to start with TDD, even if you do it only in the request code.
A standard API request usually has:
- Error handling (response codes, connectivity, timeout)
- A lot of possible states (loading, one entity, lists, empty sets)
- One or more successful responses
Depending on the context, you can start covering those aspects one at a time (I recommend following that order) or make the whole process use TDD. This is a great place to start defining the standards you will follow for the rest of the tests: tools, libraries, coding standards, and naming, among others.
2. Fix Bugs
Another easy way to start using TDD is by fixing bugs. If you don’t have much experience, you can start covering some of the methods you are about to change. After you do some tests on the current implementation, just to ensure that you are not breaking the code, create your first test to fail because of the bug, fix it, verify the tests are green, and only refactor the code covered.
3. Practice, Practice, Practice
The understanding you get reading something is very different from the understanding you get doing it. Even better than starting on work projects, there are a lot of small exercises that will help you to develop the skills you need, like:
- Roman numeral conversion
- Scoring a bowling game
- Fizz Buzz
- Conway's game
Practice a few minutes every day. You don’t have to spend hours at a time on it, but make a point to do it regularly.
4. Pair Up
I found a very interesting article about a pair programming TDD game; I consider it very useful because pair programming helps senior developers to share their experience and junior developers to learn — both of which help you to have high-quality, clean code.
There is only one rule in this game that I would change: Refactor should be mandatory after a green test.
5. Measure Your Performance
Metrics are the clearest way to know if TDD or any technique is helping you to improve, or if it is slowing you down. I saved this for the end because, in the beginning, TDD will probably slow you down a bit as you’re learning. That’s one of the reasons to avoid it in busy sprints or under tight deadlines.
Once you feel you are getting in good shape using TDD, it is a must to start measuring your current performance and find out how this is helping you to reach the company’s goals. It is your job to learn, to improve yourself, and present real data to your managers to show why this methodology matters.
Just remember, TDD is not the only way to increase your performance, but it is a highly effective method.
It is possible to start test-driven development right now if you begin with small increments and try not to do it alone.
- First, learn and practice: Find someone with experience in TDD, and try it out on side projects or small practice exercises —not during sprints or on projects with tight deadlines.
- Then, start using TDD on API requests, fixing bugs, and align your goals with the project.
- Finally, practice, practice, and then practice more.
Happy Coding! :)