While the artifact of Test Driven Development is test code, what you get out of test driven development far exceeds the test themselves.
By writing test first, you tend to write code that is more highly maintainable than if you just wrote the code to solve the problem. By writing a class so that it can be used in both the system you are writing it for and so that it can be tested, you’ve been forced to think about the code in at least one other way from what you would have initially. The result is your code tends to be more structured than it would have been otherwise.
By writing test first, you are forced to develop clearer specifications. I’ve run into this recently on a project that I’m currently working on. I can’t write a test for the code I’m about to implement because I don’t clearly understand how this is supposed to interact with the rest of the application. Until I do, I really can’t move forward. If I were not writing a test, this would not be as clear now as it is. Although, one could argue that eventually it would become clear. But it is more likely I would leave the feature out completely because I forgot about it entirely. Something I’ve been known to do in the past.
Up To Date Specifications
This leads to another advantage to test driven development that I’ve mentioned before. By writing test in advance, you have the specification coded. This forces you to keep the specification up to date if it changes because your test won’t run unless you do. How many other programming methods are there that force the specifications to be kept up to date? I can’t think of any.
A Safety Net For Refactoring
If you’ve ever looked at bad code and thought, “I bet I could make this better.” But then you were afraid to make any changes because you aren’t sure your improvement wouldn’t break something, you’ll really appreciate TDD. If there is a good test suite for the code you want to refactor, you can be sure that any changes you make won’t break something it should do. I’ve left a lot of code alone for fear of breaking something else.
Preventing Feature Creep
Another thing TDD does is that it prevents feature creep on the part of developers. Face it, how many times have you added a feature into the system that no one asked for? By coding to the test, you reduce this urge.
Many people start TDD by writing test after the fact and wonder how this can possibly be helpful. This is because they’ve written them after they’ve written the code and they’ve completely bypass 80% of the benefits.
Other post in TDD
- Why Don't You Practice Test First Development? - February 20th, 2014
- Test Driven Specifications - February 25th, 2014
- Unit Test Structure - March 11th, 2014
- When You Really Need All Of Your NUnit Test In One Class - March 18th, 2014
- TDD Isn’t All About Testing - March 25th, 2014
- Automated Web Application Functional Testing - April 1st, 2014
- What Not To Test - April 9th, 2014
- Make Your Test Work For You - April 18th, 2014
- Don’t Comment Out That Test - April 24th, 2014
- The Proper Function of QA - May 1st, 2014
- TDD Saves Time – A Story - May 22nd, 2014
- It is called "Unit Testing" for a reason - August 28th, 2014
- Is Your Architecture Crippling Your Unit Testing? - September 4th, 2014
- Selenium Performance Improvements - October 2nd, 2014
- Technical Debt Is Inevitable - October 16th, 2014
- NUnit, Unity Dependency Injection, MOQ and Private Fields - October 23rd, 2014
- NUnit & Visual Studio - December 4th, 2014
- Software Architecture without Test Driven Development is DANGEROUS! - January 29th, 2015
- NUnit Test Code Structure - February 5th, 2015
- Excuses For Not Testing - February 26th, 2015
- Why Johnny Can't do Test Driven Development - March 5th, 2015
- Changing Habits - March 19th, 2015
- 100% Code Coverage Possible? - March 26th, 2015
- TDD Gamification - Turning Test Driven Development into a Game - April 23rd, 2015
- Run NUnit from Visual Studio - April 30th, 2015
- The Parable of The Road Line Painter - May 28th, 2015
- The Fallacy of Motion - July 23rd, 2015
- Test Driven Learning - An Experiment - March 24th, 2016
- 3 Reasons You Believe 100% Code Coverage Is Impossible - May 26th, 2016