Agile – TDD/Tests too much an overhead/maintenance burden

agilebddtddtesting

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.

Best Answer

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.

Related Topic