Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So you've heard it many times from those who do not truly understand the values of testing. Just to start things out, I'm a follower of Agile and Testing...

I recently had a discussion about performing TDD on a product re-write where the current team does not practice unit testing on any level, and probably have never heard of the dependency injection technique or test patterns/design etc (we won't even get on to clean code).

Now, I am fully responsible for the rewrite of this product and I'm told that attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain. Furthermore, as it's a front-end application (not web-based), adding tests is pointless, as the business drive changes (by changes they mean improvements of course), the tests will become out of date, other developers who come on to the project in the future will not maintain them and become more of a burden for them to fix etc.

I can understand that TDD in a team that does not currently hold any testing experience doesn't sound good, but my argument in this case is that I can teach my practice to those around me, but further more, I know that TDD makes BETTER software. Even if I was to produce the software using TDD, and throw all the tests away on handing it over to a maintenance team, it surely would be a better approach than not using TDD at all from the start?

I've been shot down as I've mentioned doing TDD on most projects for a team that have never heard of it. The thought of "interfaces" and strange looking DI constructors scares them off...

Can anyone please help me in what is normally a very short conversation of trying to sell TDD and my approach to people? I usually have a very short window of argument before falling at the knees to the company/team.

share|improve this question
RUN! FLEE! Anyone who can't grasp why automated tests will make their lives easier in the long run needs to remove their head(s) from you-know-where. – MattC Jan 31 '11 at 21:55
@MattC TDD != automated tests – Nemanja Trifunovic Feb 1 '11 at 3:39
@Nemanja Trifunovic: Uhh... who practices TDD using manual tests? "I started the app but there's no button to click on!?" "Yea; that's the red in red, green, refactor!" – Steve Evers Apr 13 '11 at 23:14
@SnOrfus: There are automated tests without TDD. Some examples: automated integration tests, regression tests, stress tests. – Nemanja Trifunovic Apr 14 '11 at 0:44
@Martin, I'd be interested in a followup comment (or blog post) that discusses what you ended up doing and how well (or not) it worked for you in the long run. – StevenV Aug 15 '11 at 20:19
up vote 30 down vote accepted

attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain.

You can't win that argument. They're making this up. Sadly, you have no real facts, either. Any example you provide can be disputed.

The only way to make this point is to have code which is lower cost to maintain.

Furthermore, as it's a front-end application (not web-based), adding tests is pointless,

Everyone says this. It may be partially true, also. If the application is reasonably well designed, the front-end does very little.

If the application is poorly designed, however, the front-end does too much and is difficult to test. This is a design problem, not a testing problem.

as the business drive changes (by changes they mean improvements of course), the tests will become out of date, other developers who come on to the project in the future will not maintain them and become more of a burden for them to fix etc.

This is the same argument as above.

You can't win the argument. So don't argue.

"I am fully responsible for the rewrite of this product"

In that case,

  1. Add tests anyway. But add tests as you go, incrementally. Don't spend a long time getting tests written first. Convert a little. Test a little. Convert a little more. Test a little more.

  2. Use those tests until someone figures out that testing is working and asks why things go so well.

I had the same argument on a rewrite (from C++ to Java) and I simply used the tests even though they told me not to.

I was developing very quickly. I asked for concrete examples of correct results, which they sent in spreadsheets. I turned the spreadsheets into unittest.TestCase (without telling them) and uses these to test.

When were in user acceptance testing -- and mistakes were found -- I just asked for the spreadsheets with the examples to be reviewed, corrected and expanded to cover the problems found during acceptance test. I turned the corrected spreadsheets into unittest.TestCase (without telling them) and uses these to test.

No one needs to know in detail why you are successful.

Just be successful.

share|improve this answer
Very inspiring response there S.Lott :). It was daunting for me to be told by a company architect that I would be "creating unnecessary overhead". I couldn't be seen to be delaying the project with any unknowns to them, that ultimately if the project came in late, they could simply point the finger at the testing I performed and ended the contract. As you say, sneaking them in a proving later how it helped is probably the right way. You're absolutely right from an argument point of view, I have no grounds, and neither do they. – Martin Blore Jan 31 '11 at 22:35
Why is front-end does too much design problem? Nowadays many technologies like AJAX do much in front-end. – 卢声远 Shengyuan Lu Apr 14 '11 at 9:45
@卢声远 Shengyuan Lu: It's hard to test GUI "look". You can test fonts and colors. However, browser quirks make it very hard to test exact placement and size with automated testing. – S.Lott Apr 14 '11 at 14:45
@Martin Blore: "neither do they." Precisely. Anyone who says testing will somehow magically add risk is crazy. You have to test anyway -- it's inescapable. You can test well (using TDD) or you can test poorly and haphazardly. Planning for poor, haphazard testing seems riskier to me. But there's no basis discussion until the "nay-sayers" have hands-on experience. – S.Lott Apr 14 '11 at 14:46

You can only convince such people (if at all) from the practical point of view, demonstrating the value of TDD in real life. E.g. taking some recent bug as an example, and showing how to construct a unit test which makes sure 100% that this bug may never appear again. And then of course write a dozen more unit tests to prevent the whole class of similar bugs from appearing (and who knows, maybe on the way even uncovering a few more dormant bugs in the code).

If this does not work in the short term, you need to work on this longer, simply by doing TDD and writing unit tests diligently on your own tasks. Then compile some simple statistics after half a year or so (if it is possible in your environment) to compare bug rates in code/tasks accomplished by different developers (anonimyzed to prevent alienating your teammates). If you can point out that there was significantly less bugs found in your code than in others', you may have a strong point to sell both to management and fellow developers.

share|improve this answer
That's a great idea Peter, thanks for that. My current project has a test team so I'm sure it would be quite easy to capture bugs found in milestone releases etc. – Martin Blore Jan 31 '11 at 22:01

You have to be practical about these things, TDD is a nice thing to have in theory, but unless you're updating your tests for everything that gets added, there's little point in it - no-one wants to run a test that reports broken code when its the test that's not been updated! As a result, it can easily be too costly to do them - you're won't be the only dev working on that code.

The client has a test team.. well, there's no problem in shifting the testing burden from the developer to the testers - that's what they're there for after all, and if they find bugs through their tests (maybe they have a lot of automated testing tools) then there's little point to writing unit tests at your level. It'll take a bit longer to find the bugs, but they'll find those pesky "integration" bugs that your tests wouldn't have exercised.

Chances are this is why they don;t care for unit testing.

Lastly, TDD is a new thing, when I were a lad we never had testing and we wrote code that worked. Unit testing makes some people feel warm and fuzzy, but its absolutely not a requirement for correct code.

PS. I see another of your questions where you criticise layers of abstraction, and here you criticise the lack of DI constructors! Make your mind up :)

share|improve this answer

Since everything changes so rapidly as you put it, explain to them that it will be used for Regression Testing. Which will save a lot of headaches when new bugs are introduced because someone broke a line of code that was written 10 years ago to resolve a problem that occurs 1 out of every 10,000,000 executions of a specific function that is only called if the system clock on the client is greater than 3 minutes difference than the server system clock. Just ask them how many customers they can afford to lose because of buggy software.

share|improve this answer

Point out that finding a bug during development costs X, during testing 10X, and after deployment 100X. See if they will at least allow you to conduct a pilot test where you implement TDD in a specific module, then follow up with comparisons with other modules as they are developed, tested, deployed, and supported. Given adequate data, you should be able to demonstrate how less effort was used to produce code in the TDD module. Good luck.

share|improve this answer

Well test is burden but it is good burden to carry. It is better to do some work upfront which would save good amount of time when there is some production issue or during migration. I will always want to have test even though it is little burden but I want to carry that burden.

share|improve this answer

Yes, maintaining tests is a burden. Updating them, updating your test data: all this sucks your time.

The alternative - manually testing things, refixing bugs that regress, not being able to tell in seconds that your code works - costs a lot more.

share|improve this answer
I think this is one of the most important points to make to nay-sayers who claim TDD is a waste of time and unnecessary overhead. It's not that TDD doesn't cost time. It's the fact that it's an investment that prevent future costs that are orders of magnitude greater – kai Feb 5 at 11:18

Your Answer


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.