Test Driven Development

Development Cycles / By

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.

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.

The Process

Test Driven Development, TDD, follows a short development cycle that can be summed up like this:

  1. Before the real coding begins, the developer should write all the automated test code. This test code should account for all possible inputs, errors, and outputs.
  2. The test code should compile and run, but all the tests will fail, no real code has been written for the feature yet.
  3. Now the developer can start writing the real code. The developer can keep running the tests to ensure that all the parts of the code function correctly. The developer will know that the feature is complete once all the tests pass.
  4. Woot! all the tests have passed. Now the developer can optimize the code and begin clean up. As long as the tests still pass, then the feature will work without breaking other code.
  5. Start the process all over again with the next feature.

So this doubles my work, can’t I just test my program when i’m done coding?

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.

What’s the Process

  1. Design a project, get the requirements
  2. Think about the features one by one. You need to really think about all the possible inputs and outputs for each feature.
  3. Start writing test cases for each function that assert the expected inputs and outputs.
  4. Run the test cases. They should all fail. No meaty code exists yet. If any pass then they are probably bad tests.
  5. Now that the test cases are written to expect certain results, it’s time to answer the test with proper results by coding.
  6. Re-run the tests ensuring that each part of project returns the proper results.
  7. Once all the tests pass, it’s time for code cleanup. The developer can optimize the code and rerun the test to ensure no new bugs are introduced.
  8. Move on to the next feature and repeat. Remember to re-run all the tests to ensure everything functions down the line.

Conclusion

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.