Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Quite often benefits of using TDD are considered as 'long term' gains - the overall code will be better structured, more testable, overall less bugs reported by customers, etc.

However, where are the short terms benefits of using TDD? Are there any which are actually tengible and easily measureable?

Is it important to have an obvious (or even not obvious by quantifiable) short term benefit at all, if the long term gains are measurable?

share|improve this question
add comment

3 Answers

There are some short term benefits to TDD, some more measurable than others. Here are some from the top of my head:

  • Clean code, following the good ol' SOLID principles. That is if you keep your tests as clean as your code and avoid dirty hybrid test code, the code will tend to follow SOLID. Clean code is easier to read and is easier to maintain your code from start. Man hours are saved during maintenance, but short-term wise: you'll get to cleaner code quicker (because you have some tests to back you up).

  • Regression testing from start; you broke it you'll know about it… early. Backed by a CI server, this is will save you some hair. The man hours to fix a regressed bug that you'll discover early without tests is hard to measure but lets just say it's a lot of man hours.

  • Enables refactoring to be done without too much guesswork. If you got a test suite done for a class, refactoring it (like extracting methods, using other data structures, extracting classes) will be easy because you've defined the tests from start. What would take days to refactor one class will take less than one; and you can do it right away if you have the tests done from before.

  • Test driven design lets you fix code duplication early. At least if you're observant programmer; because testing with duplicated code (both in test code and production code) becomes quickly a dull task. The smarter you are with your test code, the better it'll get. Less code, less hassle, more man-hours saved.

EDIT Also added by Frank Shearar, which I happen to agree:

At any point you have working code (except the test case you're currently working with).

Finding bugs or design issues early through TDD is really invaluable and is difficult to measure how much you save in man-hours; though one way would be to count the hours you've previously spent on working on design issues late in development. With unit tests a subset of your code can be exercised through your tests without having to run your actual application or system. That way you can assure yourself through TDD that some part of your program is working right now, even though it may not be hooked up to the real thing at the moment.

share|improve this answer
2  
And: At any point you have working code (except the test case you're currently working with). –  Frank Shearar Jun 27 '11 at 8:43
    
+1 @Frank - this is a good one to emphasize. –  ratkok Jun 27 '11 at 14:22
add comment

By short term do you mean small projects, or do you mean the early days of a project?

I'm of the belief that getting tests integrated while laying the early groundwork will pay dividends right away because you've verified the pillars upon which the entire rest of the project will stand. I tend to design from the top down and implement from the bottom up so this makes sense for my way of working.

If you so much as catch one inconsistency now, your work has just paid for itself by not having to debug a more complex program later.

Plus your project is already setup for testing and you won't have to refactor a rig in later.

share|improve this answer
2  
Growing Object Oriented Software Guided by Tests calls this a "walking skeleton" - a minimal structure that allows a complete end-to-end test of your architecture, and is automatically deployable. Once you have that, you can safely and steadily put flesh on the bones of the application, knowing that as you do, all your code works, and you can deploy at any time. –  Frank Shearar Jun 27 '11 at 8:44
    
What I mean by 'short term gain' is the benefits that you gain by doing TDD which can be seen/recognized in short period of time - regardless of the size of the project. And 'seen/recognized' not just by people who are doing TDD but other as well (managers, PMs, customers, etc). –  ratkok Jun 27 '11 at 14:20
add comment

A very short term benefit I find from TDD is that I don't have to concentrate so hard on what I am trying to achieve.

If I get interrupted from my work, without TDD it takes a few minutes to remind myself where I am when I get back to the task.

With TDD I just run the tests see which one fails and instantly I know what I was trying to achieve. I work quicker with less brain ache.

share|improve this answer
    
This is an interesting one - never thought of this benefit. However, this might seem that TDD would encourage or support multitasking which I believe is somtething that agile and XP really try to minimize (if not eliminate). –  ratkok Jul 3 '11 at 12:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.