Photo by Robert Haverly on Unsplash
What is Test Driven Development?
Test Driven Development (TDD) is the process of writing tests for your code before writing any real code that produces actual functionality for your customer. It’s a somewhat controversial development style that involves a short, repetitive cycle of development. You write a test, watch it fail (red), write the implementation, watch the test pass (green), and refactor. You repeat the cycle of red, green, refactor as you build out the system.
There is a lot of debate about whether or not TDD improves the quality of your code and reduces development time. However, studies have shown that it is one of the most effective development techniques and it increases productivity.
Because of these studies, at Steele Consulting, we encourage our developers to use TDD.
Benefits
Maintainability
One benefit of TDD is that it makes your code more maintainable and flexible. Because the tests drive the code and build it piece by piece, each part is easily distinguishable and changeable, and not as tightly coupled. This makes your code easier to change, update, refactor, and debug.
This is especially useful when it comes to a project’s design because it’s common for your design to be altered as a project is built out.
Reduced Maintenance Costs
Another benefit of TDD is the time and money it saves you in maintenance. Code maintenance is typically the most expensive part of software projects; TDD can reduce maintenance costs because it reduces the number of production bugs by 40-80%. To put things in perspective, one production bug can take ~15 hours to fix; assuming you’d have 100 production bugs without TDD and only 60 bugs with TDD, you’d save about 600 hours worth of maintenance costs.
Business Metrics
Test Driven Development also has multiple beneficial effects on your business metrics.
- Developer Productivity
It improves developer productivity long term. While someone using TDD (initially) only codes 50-75% as fast as someone who isn’t using TDD, the code that results from TDD is cleaner and easily maintainable; it prevents problems from stacking up on each other. A developer who isn’t using TDD would get slowed down by the time they reached production; a developer using TDD would maintain a steady and consistent pace, and they’d ultimately be more productive.
- Customer Abandonment
TDD reduces customer abandonment; if you have better quality, bug-free projects in your portfolio, it strengthens and lifts your market value, and potential clients will be more likely to commit to a contract or purchase.
- Viral Factor
It increases the viral factor of the app you’re developing. Unsurprisingly, high quality, smooth applications are more likely to become widespread than low quality, buggy applications. Even internal applications, like a delivery service’s driver tracker, can be ditched by the employees if they’re low quality, so the intended benefits of that application wouldn’t get reaped by your client.
- Customer Service Costs
It reduces the costs of customer service. If there are fewer bugs in your code (because you’ve tested it properly), the customer will run into fewer issues that customer service would need to solve.
TDD Opposition
“It’s a waste of time!”
Some people may say that TDD is a waste of time, since it takes longer for the project’s initial build out. However, TDD ultimately ends up saving you a lot of time because it reduces production bugs by 40%–80%, and production bugs take 15 times longer to fix than bugs at design or implementation phase.
“It limits your design!”
Another argument against TDD is that it can damage design, or limit your design because it needs to be easily testable. James Shore puts it best when he says, “TDD doesn’t create a design. You do.” To blame a bad design on TDD is irresponsible; it is up to the developer to create a good design. A good developer wouldn’t let testability get in the way of or damage the design, so if TDD is making your code worse, you either need to change the way you design or change the way you do TDD.
“It’s too hard to learn”
The last main argument against this practice is that it can’t be realistically implemented. Opposers of TDD believe team members who don’t already know/practice TDD would take a long time learning it. While it’s true that TDD can be hard to learn, saying that it is too hard just shows a lack of discipline and software craftsmanship. TDD literacy is easily achievable for a developer has a will to learn and the right tools to do so.
How to Get Started with TDD
Testing the Waters
A good way you can familiarize yourself with the process and feel of TDD is to write a practice app. You can make this anything you want. However, when you’re getting used to TDD, it’s better if you’re making something simple, like a “Hello World”. Additionally, you can practice TDD with Katas. Katas are detailed or defined sets of movements to be practiced over and over again, which will help you build tolerance for the repetition of the TDD cycle. You can find a collection of TDD Katas here.
Doing Your Homework
There is no end to blog posts and lectures on TDD. Clean Code by Robert Cecil Martin talks about TDD, and he’s also got lectures about it on YouTube. It’s also a good idea to look into the different approaches of TDD before applying it to a real project to figure out which one is best suited to your application.
Resources
A brief list of links to the resources used for this post.
If you’d like to keep up with more of Steele Consulting’s developer insights, follow us on Twitter to get notified of new posts.