Some people are not testing friendly

[Hussein Baghdadi]

Hi again.
Some people in our industry don't believe in unit testing.
Some say it is a great way for wasting time (writing a test then writing the code !).
Others will say that testing the application during the run is the testing.
How can we respond to these kind of false statements?
Thanks.

[Razvan Popovici]

I think the reason is purely financial. The tests cost money. If you work for a single or a few customers, correcting a problem from the beginnings will cost the same amount of money as correcting it while in production, that's so called bannana products, they are delivered green and mature at the customer. On the other hand, if you have a lot of customers, then you would spend much more money on correcting a problem in production as you would spend in development.
Despite of this logic, there are companies who don't want to invest more in quality assurance, because of no imediate incentive, they even consider the cost of deployment "normal".
The third category are the CTOs/deciders with no idea about testing, or at least no continous testing.

[Charles Hasegawa]

Show them that the cost of change and finding defects late in the development of a product is expensive.

The fact is, unless you are truly an advocate for TDD, its hard to explain the benefit to other devs, let alone the people managing the projects and money. The fact is, with a good suite of tests, making changes to the code is usually painless, because you know if things have broken right away, instead of trying to guess whether the changes work. When you are fixing bugs, you can determine immediately if you fixed the bug AND if you introduced any new ones. A smart manager will realize that his developers should spend time putting in tests NOW and release a quality product so that they can spend time in the future working on new work, rather than releasing buggy code that requires post-release resources to fix.

[Nguyen Hai]

One function does not write only one time. And the cost of project may be run fast when you perform regression test regularly. Write test code perform automation test is the best way to find programming/design defects can be occurred when you implement some module. Perform unit test regularly is the way make your program testable ---> your design becomes better.

Some think that instead of writing code they must writing code + test code. The effort seems to be greater but it is wrong. Time for completing one program = time for coding + time for testing + time for fixing defects (include debugging time). Spend time for writing test will help us reduce time for developing.

Hai, Nguyen Phuc
http://www.haiphucnguyen.net/blog/

[Jeff Langr]

Originally posted by John Todd:
Some people in our industry don't believe in unit testing. Some say it is a great way for wasting time (writing a test then writing the code !).

Greetings John,

I'm at the point where I think "just" unit testing is close to a waste of time. Writing tests *after* the code is fairly expensive. It doesn't improve the design, and in most programmer's minds it only serves the job of verifying code that they already "know" works. It usually only gets you to 70% or so coverage, which isn't enough to comprehensively document the system or to allow confident introduction of new code while keeping the code clean.

In another thread I posted about all the things that TDD does impact, including design and documentation. It also afford continual refactoring, something essential to keeping the code clean and the system sustained over time.

Over time, not doing TDD produces a rigid, brittle system, one that developers are afraid to touch. I'm working on a system now that exhibits this problem. It costs probably 10 times what it should to maintain, because developers have feared doing the "right" thing with respect to the code and design.

Jeff

[Craig Bayley]

We are currently implementing a series of agile/XP processes, automating our testing, etc. We've just introduced pair programming as a trial, and the first thing people are working on is getting the existing problems down so we can see the wood for the trees. When the team were working alone refactoring and tifying up JUnits, they found it heavy going, but working in pairs helped, as they had a Camaraderie of drudgery.

Of course, better to write tests that worked in the first place, and develop the tests first, but we have to start somewhere....tiny steps.

[Ilja Preuss]

Originally posted by John Todd:
Some people in our industry don't believe in unit testing.
Some say it is a great way for wasting time (writing a test then writing the code !).
Others will say that testing the application during the run is the testing.
How can we respond to these kind of false statements?

You already got a lot of good responses for dealing with the facts. One additional thing you should consider is that almost all decisions humans make are based on emotions, not facts. So the reasons that you talk about might in fact be secondary to the true reasons.

Some reasons TDD might get rejected that you are unlikely to hear spoken out loudely are:

- people think that it won't be fun,
- people are not sure that they can make the transition,
- people don't feel save to fail - while failing is inevitable when you try something new,
- etc. pp.

You might need to address some of those hidden reasons to successfully convince someone to try TDD.

"Fearless Change" is a great book an this topic.

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
people don't feel save to fail - while failing is inevitable when you try something new

Any thoughts on how to address this one?

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

Any thoughts on how to address this one?

I can think of two root causes for this:

- time pressure: there really is "no time to fail". In that case, you need to provide room for experimentation. Build slack into the schedule in respect of the time it needs to learn a new technique.

- cultural: if failure is perceived as weakness, people aren't motivated to experiment. You need to form a culture where experimentation is rewarded and failure is celebrated as an opportunity to learn.