We all know that testing code can really get annoying after awhile. But it isn’t often that developers create magic code that compiles and runs perfectly on the first try. Not testing our code fully can lead to several problems down the line once we hit the masses in production. To help making testing easier while producing better code we have Test driven Development.
Developers and code bugs have been at war for as long as programming has existed. No code is truly safe so we need to test it. Creating new features and expanding our product and trying to ensure that the old stuff still works is a real problem. The solution, Test Driven Development or TDD for short. TDD is a programming technique that requires developers to write code and automated test code simultaneously. This ensure that the code is fully tested and enables rapid re-testing of the code when new features are added.
Test Driven Development, TDD, follows a short development cycle that can be summed up like this:
Requirements are pouring in, the timeline is set, let’s start coding. You are halfway done and you get a call, X feature needs to be tweaked, then another call, blah feature needs to be added, and another call the timeline has changed. Once you changed feature x did you test features a, b, and c again? The timeline has shrunk, did you just skip testing the email validator function because it’s simple? The product is 99% complete and you didn’t have your 2:30pm coffee and release is at 5pm did you cover everything one last time?
Most of the time the general run through testing works. The product goes live and users discover a minor typo or something is shifting that shouldn’t be. But what if the update rolls out to 1000’s of customers and if they change their email they can no longer use the product. You think email changing is such a small feature in the back. That code hasn’t changed in months. Nobody tested it. Now management is breathing down your neck. You are running double time and email change works for you. Turns out if they change their email and then browse to x page everything breaks. Now you are looking at a really late night patching bugs, trying to not create new ones while everyone’s eyes are on you. Now you have to run through the entire program testing everything manually and hoping you didn’t miss anything. If the program breaks again, the company looks bad, the product looks bad, you look bad.
Wow that got intense, TDD was created to help eliminate these issues. When a program is created using TDD, it allows the developer to create features, make changes, and expand the product while being able to test quickly. Add a feature, run the unit tests and boom, did it pass, did it fail. If it passes we know we are still good, if it failed then we can dive in and figure out what went wrong. The whole process is automated and allows developers to easily spot the exact point where the code failed locating the bugs easier.
Testing is a very important part of the development cycle, ensuring that the product functions as expected. However, developers tend to overlook this aspect. Using Test Driven Development means a little extra work up front, but a lot of time saving later on. Please spend some time looking up Test-Driven Development processes for your programming language and hopefully once you invest a little time into Test-Driven Development your products will be cleaner, and your testing costs will be lower.
