Why TDD doesn't work
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
Member 4487083 wrote:
In most teams there seem to always be people who won't/can't/don't write useful tests,
I would think that any larger teams it really is not just about the tests, but just bad programming in general. Just because it compiles does not make it good, or correct. TDD is suppose to answer that. However, throwing the same bad programmers at the TDD end will just amplify the problem. Not a TDD nazi nor do I practice it. One need be on the upfront building to practice true TDD. Building tests after the fact is not TDD. It is Unit testing, but clearly you can not say the development was driven by the tests as the development is 'done'. In the end, I really think QA working closly with BAs should be in charge of TDD. They could have it all done before even bringing in the actual developers. To some this may sound crazy because you are then asking your QAs to understand coding. To me it is silly to have someone quality testing something that does not understand the basics of its building. In no way do Unit Tests need the speacialization that the actual developers will provide. For example you do not need a ASP.Net, Silverlight, Parallel guru, MVVM expert etc. etc. to build up tests around the business requests. You need only understand what the business is asking for (your BA) and understand how you can prove you are providing it (your QA) Once that is set up the team can then develop the system. Your QA has it easy because they built the tests so they understand them fully. But in reality the QAs tend not know much about coding. They are asked to test and not even provided proper testing tools. Essentially they are winging it. In this case the Unit Tests are just an assurance to the developer that their QA will not loose their job if the system backfires. Why the QA? Cause they give the OK. If they continually say :thumbsdown: to the dev then the dev is facing termination. But when under the gun from upper management rarely will someone give a system :thumbsdown:, so in the end it becomes their fault.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
I've yet to work anywhere where TDD has been done properly. It all ends up as unit testing (nothing wrong with that, by they way) followed by QA and UAT. In any case, I've yet to be convinced that up-front testing is any better than back end testing when you are working in an 'agile' environment with needs changing and evolving constantly. I'm sure someone will tell me that is exactly why you need TDD: but how do you do that when you have limited time and resources and need to get the job done in an ever changing landscape with constantly shifting goalposts?
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
Your experience is what usually happens. People learn about TDD from conferences and hype, and then they try to implement it without understanding its basics or realizing that you need to carefully manage and enforce it for it to be worthwhile. If you had a code sergeant who enforces good unit tests with an iron fist, you could end up with a robust, uniform system, but most developers will screw up the whole test suite without realizing it.
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
I recently interviewed a guy who claims to work in a TDD team, when I asked him the cost of TDD in time he said it basically doubled the development time, reduced the testing time but rarely is that seen. We do unit and UAT, sometimes build automated unit tests but are certainly not TDD. We simply cannot afford the resource for this, the idea that you could do the TDD and still have a crappy system if it is done wrong only reinforces that stand!
Never underestimate the power of human stupidity RAH
-
I have been using TDD and pushing it for a while now but I think I'm coming to the conclusion that it doesn't work. The problem is not with TDD itself, but with trying to get a team to use it effectively. With a single developer, two keen developers, or maybe 3 keen developers, you've got a chance. In most teams there seem to always be people who won't/can't/don't write useful tests, which means you lose all the benefits. When these people do write tests they are often unmaintainable. There are also a lot of teams that say they do TDD, often don't do it well enough for it to be beneficial. The complicated bit don't have tests, they aren't maintainable, and in many cases they just wrote the tests because they had to. The majority of people also seem to write their tests after the code, which isn't quite the same as TDD. Has anybody had real success with TDD? For me it seems like an ongoing battle, and a waste of time because there is so little coverage.
Member 4487083 wrote:
Has anybody had real success with TDD?
I have certainly never met anyone that seemed to express to me in a believable way that they have had any real success with any process methodology. Where real success would represent some improvement that is measurable even if not actually measured. Plenty of people claim that they use a given methodology X successfully but there are others that claim that X failed. Failures always seem to be the result of improper implementation and not a fault of the methodology. While claimed successes seem more imagined than real. I have in the past read of success stories with CMM, where there were actual measured results, but those seemed more like exceptions than the norm (sort of like comparing Olympic gold medalists to weekend joggers.)
-
Member 4487083 wrote:
In most teams there seem to always be people who won't/can't/don't write useful tests,
I would think that any larger teams it really is not just about the tests, but just bad programming in general. Just because it compiles does not make it good, or correct. TDD is suppose to answer that. However, throwing the same bad programmers at the TDD end will just amplify the problem. Not a TDD nazi nor do I practice it. One need be on the upfront building to practice true TDD. Building tests after the fact is not TDD. It is Unit testing, but clearly you can not say the development was driven by the tests as the development is 'done'. In the end, I really think QA working closly with BAs should be in charge of TDD. They could have it all done before even bringing in the actual developers. To some this may sound crazy because you are then asking your QAs to understand coding. To me it is silly to have someone quality testing something that does not understand the basics of its building. In no way do Unit Tests need the speacialization that the actual developers will provide. For example you do not need a ASP.Net, Silverlight, Parallel guru, MVVM expert etc. etc. to build up tests around the business requests. You need only understand what the business is asking for (your BA) and understand how you can prove you are providing it (your QA) Once that is set up the team can then develop the system. Your QA has it easy because they built the tests so they understand them fully. But in reality the QAs tend not know much about coding. They are asked to test and not even provided proper testing tools. Essentially they are winging it. In this case the Unit Tests are just an assurance to the developer that their QA will not loose their job if the system backfires. Why the QA? Cause they give the OK. If they continually say :thumbsdown: to the dev then the dev is facing termination. But when under the gun from upper management rarely will someone give a system :thumbsdown:, so in the end it becomes their fault.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
BAs should be in charge of TDD
This sounds like acceptance tests eg. what FitNesse is used for. I haven't tried this in the real world although it does look interesting. Maybe this is the way forward rather than writing unit tests?
-
Your experience is what usually happens. People learn about TDD from conferences and hype, and then they try to implement it without understanding its basics or realizing that you need to carefully manage and enforce it for it to be worthwhile. If you had a code sergeant who enforces good unit tests with an iron fist, you could end up with a robust, uniform system, but most developers will screw up the whole test suite without realizing it.
I think part of the problem is with the difficulty of writing testable code. Eg. How would somebody write good tests if they don't understand dependency injection? You also get people who write functions that are hundreds of lines long and writing testable code would be difficult for them.
jesarg wrote:
If you had a code sergeant who enforces good unit tests with an iron fist, you could end up with a robust, uniform system, but most developers will screw up the whole test suite without realizing it.
Would you have a happy and productive team though? Devs will often skip the tests when they are under pressure, and when they're under pressure they probably wouldn't appreciate criticism.