Otaku, Cedric's weblog

"Keep in mind that functional tests are the only tests that really matter to your users"
Yay! Someone thinks like I do!
Great book by the way. Any chance there will be an updated version covering more aspects of Enterprise Testing?

I attended an agile architecture by Jim O'Coplien last year and he brought this anti-TDD argument up on the course.

I was not convinced. The whole argument was a bit of a straw-man. According to the argument TDD is mostly about getting the failing test to pass, and the rest (refactoring) is not included. I guess if one considers design and conscious architectural choices to be forbidden by TDD, then the practice fails..

I agree on the point that TDD alone does not guarantee quality.

Glad to see that someone who has really done some heavy lifting in the unit testing community call out the zealotry that surrounds TDD. To wit my own experience with TDD:

orangepips.instantspot.com/blog/2008/03/03/TDD-Backlash

Hmm... I do test-first, mostly, but it can just as easily be *functional* test first. Not everything needs to be unit-tested, but there should be a test somewhere that exercises the code you're about to write.

Also, while I don't think developers should feel bad about not doing TDD, maybe they should feel bad about not *trying* it, because not trying a technique that has worked so well for others shows a basic lack of curiosity and rather complacent attitude about your own performance as a software developer.

My experience with TDD has been positive - over two years on complicated financial calculation engine. It is definitely not a toy. I don't have a book to hawk or lecture circuit to sell. What I have seen is that, more often than not, when a test was hard to write, it was an indicator of "ugly" coupling in the design. There are no absolutes but having taken this component thru system integration testing, customer acceptance test and then into production, all of the extra effort developing unit and component level tests was well worth the effort.

This was probably the most complicated component I've developed in 20+ years and it resulted in the lowest stress levels I've experience in during CAT and production rollout.

From my point of view, I think your underestimating the value of the "luxury" for the developers. I have experienced and witnessed the infamous coding with fear. Six months into a project, something isn't right and no one wants to change it because they don't know what else might break. With new developers, its more like 6 weeks. Being able run test suites, at the unit test level, removes much of the fear and stress that developers feel with making changes in a code base that is bigger than what you can get your head completely around.

Personally, I love working without all of this stress. Does TDD remove all stress? No. Does it make a real quality of job / life difference? For me and my team on this project, yes, it did.

Just my 2 cents.

Iam very happy to see some one stand up against the
TDD Extremism, From my experience TDD has ruined Design aspect of software development,(esp when it is taken to the other extreme), and when you have already developed complex systems, it is useless , besides, fitting the design to accommodate a test does not look/seem right, people should not follow blindly, they should decide as to appropriate when to use unit test, the only case where i would use TDD are when you have some formula in your code, or some thing simple like calling a webservice...
for complex system involving many systems no chance...

i just read article about TestNG , this comes to close as to what iam looking....

i would love to read your book and use Test NG...

Keep up the pragamatism.... and the good work related to Test NG.

Good Luck

I have been doing TDD for awhile now, and am beginning to question it seriously. I find myself worrying more about the coverage metric while doing TDD, and less about functional paths through the code. Or specific use cases.

I am still debating TDD's merits but I really appreciate your post. It is thoughtful and well written as always. I agree with Brian that people should try (and understand) TDD seriously, before dismissing it.

But I like to think of unit tests as part of code unlike your statement about them being a luxury, though I take the intended point.

Nice piece Cédric. Maybe TDD extremists should do more GUI work ;-)

Quote:
>> When it comes to testing, I live by the following rules of thumb:

* "Tests first" or "tests last" is unimportant as long as there are tests." <<

Sorry, but you missed the point of TDD. TDD is not about testing, but about specifying verificable behavior! The tool used there - unittesting - is of course not applicable to all situations, and fails, when you cannot isolate your unit under test. Unittesting works with isolatation. UIs not written in the style of MVC (or better: PassiveView or SupervisingController) lack this requirement. Hardware interactions also lack this requirement. Unittesting works for rich domain models, it works for all sort or oo-units, when isolatable.

-Sebastian

Who's the extremist ?

I fail to see Robert C Martin "extremism" in his writings, whereas I clearly see a very extreme position stated in this blog entry.

Dumbs up for Sebastian's comment!

alex6
PS: nobody said doing TDD was easy. And yes, TDD is not a Silver Bullet.

Hi Sebastian,

You're not the first one to say "TDD is not about testing, it's about XXX", where XXX can be either of "designing", "process", "quality", etc... It's the first time I read "verifiable behavior", though, and I'm still unconvinced.

Most of the code that I see and work with has verifiable behavior, but this term is so vague that I'm not sure that it means anything anyway...

I noticed the same issue when listening to the refactoring episode of se-radio.net.
The meltdown is caused by naive use of YAGNI and "do the simplest thing that could possible work", leading to major and expensive refactorings later (and since refactoring focus on code dependency, is even harder to "evolve" it to a good conceptual design). Writing the "test" first is to write an executable specification for the object/component, and that's very low level design. The test should be the output of the design and not the driver.

BTW Cedric, I really enjoy your kind of "anti-hype" posts. Your defense of design patterns prompted me to write my own :)

If you follow TDD naively and think that "do the simplest thing that could possibly work" means taking shortcuts, then of course it will fail. TDD and YAGNI does not tell you that design is unnecessary. Rather it tells you to continously reflect on and improve your architecture. The rythm is "Test, implement, REFACTOR", not "Test, implement, done".
I completely agree that TDD does not fit everywhere, but I would certainly say if fits in most.
"...TDD has ruined Design aspect of software development...". Ok, sure. If your big design up front always works, then that's true...
Please remember that most agile/XP methods in your toolbox are not processes to follow blindly, but tools to help you improve your software development process. The most important thing is to reflect on what you are doing and why you are doing it.
Test first and test last makes a difference in my opninon. Why? If I test first, I specify the behaviour of my class/component, and I create code that is loosely coupled and easy to test. If I write the test afterwards, I often find myself refactoring a huge part of the code to allow it to be tested. So I don't see that this is always a benefit.
TDD is no silver bullet. You can use it without ignoring the design of your application, as long as you reflect on what you are doing

'"Tests first" or "tests last" is unimportant as long as there are tests.'

I agree.

How about design first? Is that important? Cos you know, in TDD, tests aren't really tests...

TDD is not a silver bullet. It does not excuse you from thinking. Bad programmers are going to write bad code with or without TDD. Good programmers are going to write good code with or without TDD.

Good programmers who use TDD to the extent that it makes sense are benefited. Lower stress and fear are typically experienced side effects. Perhaps it's not for everyone, or every situation. I think it's currently particularly ill suited to multi-threaded programming. Currently, there aren't super good tools, techniques and teachers for doing TDD towards the GUI. Database programming with TDD requires a lot of work, and may or may not be worth it depending on your situation.

For most core code, I would argue that it's net beneficial.

As you shorten the time between when a bug is created, and when a bug is fixed, the quality of your program improves. TDD is an effective tool in most instances for shortening feedback loops. It also makes your progress more predictable.

If TDD doesn't work for you, then you won't work for me.

-Kelly

Great post Micheal!!

i'm always please to hear someone going against the grain and thinking for themselves as it definitely encourages some good discussions. I have to say that in my experience, i must wholehearted agree with Scott Hickey's comment:

"...more often than not, when a test was hard to write, it was an indicator of "ugly" coupling in the design."

TDD is a tool, as you quite rightly pointed out, but what it really forces is the thought. 99% of coding happens inside your head, and TDD really forces you to consider the interface of your code.

I agree that it doesnt suit all situations, and being made to feel like a second class coder for not doing it is particularly harsh, but on any code that is likely to be around for more than a couple of months, it will undoubtedly prove invaluable to have a test suite to run when coming back to the code.

Imaging the rails codebase without it!! Euurgh!!

Sigh. Sounds like a lot of people are suffering from the dreaded disease "versusitis" (see www.ambysoft.com/essays/versusitis.html ) which limits their effectiveness as professionals.

Be that as it may, here are some thoughts:
1. It's Bob Martin, not Rob Martin.

2. You can, and should, combine modeling and TDD. Agile Model Driven Development (AMDD), see www.agilemodeling.com/essays/amdd.htm , combines the best of both techniques.

3. AMDD helps to scale the specification aspect of TDD. See www.ddj.com/architect/205207998?cid=Ambysoft . Continuous investigative testing scales the validation aspects of TDD.

- Scott

> "Tests first" or "tests last" is unimportant as long as there are tests.

I think a better version would be: "test first" or "test X" is unimportant as long as they are done in reasonably tight cycles.

You don't want to write too much application code without writing associated tests, and you wouldn't want to write too much test code without writing the associated application code.

After all, you're going to spend a lot more time iterating between the two than you are on the initial construction.

Hi Cedric, a few thoughts;

-"Tests first" or "tests last" is unimportant as long as there are tests."-

Timing of testing changes the resulting system surprisingly. Therefore the choice is important. Which choice is better depends on the programmers skill-set, experience, interests and point of view. But it is important.

-Try to think about testing as early as possible in your development process.-

Testing is too important to do in a possibility. It should be done early (weather "test first" or "test last").

-Don't let one liners contradict your experience. For example, don't listen to people who tell you to write "the simplest possible thing that could possibly work", also known as YAGNI. If your experience tells you you're going to need this extra class in the future even if it's not needed right now, follow your judgment and add it now.-

Your experience still be there in the future when you need that class. Whether your system is open to a new class or not is absolutely depends on your design quality.

-Keep in mind that functional tests are the only tests that really matter to your users. Unit tests are just a convenience for you, the developer. A luxury. If you have time to write unit tests, great: they will save you time down the road when you need to track bugs. But if you don't, make sure that your functional tests cover what your users expect from your product.-

I agree about functional tests. But unit tests are not only for bug tracking. We have great debuggers for that right? The main purpose of unit tests (for me) is fast feedback. You changed something and not sure system still works. Functional tests take a couple of hours to run, and you don't want to argue with QA again. What will you do? Well..don't change anything? :)))

-Don't feel bad if you are not doing Test-Driven Development. There are a lot of factors that make this practice a bad fit for a lot of projects and developer personalities-

I do agree. I've worked with many software organisations and programmers which are not fit for TDD. Also I've worked with many software organisations and programmers which are not fit for software development at all. I do not mean if one can't handle TDD he/she can't handle Software Development. But if something does not fit to someone, this does not mean that thing is not excellent for someone else.

One important point. If TDD did not gone well for a project this does not mean TDD does not fit that project. It actually mean TDD does not fit to the project team, their style, their point of view, their experience and so. Another agile shop can handle the same project pretty smoothly, there are countless examples around me from all size.

Good points Cedric,

*rant follows*
Why is there such a strong tendency in this industry to take every useful tool, technique or idea to extremes and turn them into religious mantras? It's like large swaths of the community suffer from an unethical obsession seeking the "Golden Hammer" to end all discussion about what works in delivering good software.

On the one hand, the extreme converts are useful to truly explore a given technique and better improve our understanding of far something can be taken, but too often normally bright people get caught up in the times and end up abandoning Common Sense** to follow the latest fad with someone else's best practices and principles: Perhaps gaining some experience, adding a valuable tool to their arsenal, but frequently just out of a combination of boredom and rebellion.

** oh, lest I forget, I shall make my mark advocating the new Common Sense Driven Development (tm) methodology, and write a trilogy starting with "Extreme Common Sense Development", follow up with the "Pragmatic Common Sense Developer's Guide", before I repent with "Common Sense Refactored".

Good post . . . I largely agree with the general sentiment. I work at a place (Guidewire Software) that has over 36,000 unit tests running continuously, and we’ve tried just about every testing trick or methodology you can imagine, so I feel somewhat qualified to talk about the subject.

There are a few important lessons that we’ve learned. One lesson is that “unit” testing isn’t as valuable as you’d think and that higher-level tests (i.e. what functional tests) are more valuable. We’ve had situations where all the “unit” tests were passing but the application was totally broken because the parts didn’t fit together properly and we didn’t have enough higher-level tests to detect it. We’ve also gone from trying to mock out things like the database to just giving up and running our whole app stack in all our unit tests (including an H2 database). Basically, anywhere that the test code diverges from the app code paths is suspect for us; it leads to issues where the tests don’t catch bugs between components because the tests mock things out and the mocks don’t really properly encapsulate the full range of behaviors of something (mocking out a database being a good example), and it also leads to problems where simple refactorings of the code lead to test-fix death-marches where 6,000 unit tests are written expecting that some part of the app behaves in manner X, so a 2-day code change becomes quite literally requires a month of test fixing. So maybe that’s not how Coplien sees an architectural meltdown happening, but it’s what I’ve seen happen: your unit tests are a double-edged sword, and when you’ve still got tests hanging around from version 2.0 when you’re working on version 6.0 there’s going to be some serious drag from old tests just like there’s drag from old code.

The upshot is that bad tests are worse than no tests, since they just exert a huge amount of friction on your code base and actually make some changes harder. And some things are just inherently hard to test, and while that often means you need to rewrite the code in question it isn’t always worth it. I’ve seen TDD make code worse (i.e. harder to understand) by decoupling things so fully and behind so many different interfaces that it becomes much harder to follow. I’ve also seen TDD make code better by causing things to be decoupled in a way that actually works.

What I really, really hate is when the TDD/agile advocates blame the user instead of the tool. Too often the assumption seems to be that TDD/Pair Programming/Agile Practice X is perfect and that if it doesn’t work for you it’s because you’re doing it wrong. Not all writers write the same, not all painters paint the same, so why do people think all programmers program the same?

At the end of the day, my job as a software developer is about getting quality software that we can sell out the door in a timely fashion. That’s the metric against which all other things must be measured, and it’s always a trade-off. Sometimes it’s worth rewriting a class to make it testable, sometimes it’s not. Sometimes it’s worth spending 2 days fixing some tests, sometimes it’s better to just delete them. It all depends on your code base, project, time constraints, and team composition. Last time I checked, people have managed to write software for the last 30 or 40 years using tools that essentially look like rocks and sticks compared to things like IDEA or Eclipse or languages like Java and Python, so I’m guessing that there’s more than one way to properly develop a working piece of software.

TDD is a great tool, but being blind to its limitations or the tradeoffs that you have to make as a developer of real-world software isn’t a great way to develop.

Cedric, are you on the Kansas State Board of Education?

I think it's been said well here, but I'll just add my voice. Anything that claims to be the magic bullet solution isn't. Software is hard, and it requires smart, dedicated people, thinking clearly, communicating with one another, with enthusiasm and creativity.

I think TDD is a *great* tool, especially if one expects it to deliver in terms of analysis more than QA. I think all devs should know how to do it, and should know good techniques (mocks, shunts, dependency injection, endo-testing, all that) but it's not enough by itself.

-S-

Mr. Ambler,

At some point we'll look back at these all the terms, methodologies, processes et. al. and have a good laugh...I mean AMDD?

"AMDD helps to scale the specification aspect of TDD" (uhhh... what?)

Heck, I'm still wondering whether the acronym TDD stands for "test driven development" or "test driven design"?

At the end of the day, the software must work for the end user. He doesn't care you did TDD, AMDD, FUD or BAD!

For the thought leaders of the world:

Please share your experience with us. But don't expect us to follow them exactly the way you want us to.

I don't know Jim Coplien. He sounds like a smart guy since it says "software guru", so that means I'm inclined to listen to him. For C++ books, I'm more of a Scott Meyers fan myself. The problem is that I must be doing YAGNI/TDD incorrectly because none of my projects have melted down in iteration three. What I'm most disappointed in is that Jim says it will be an architectural "melt down". In my experience, the worst cases have been that I have to do some refactoring and that is nothing on par with "melt down" which brings to mind Chernobyl or the China Syndrome. If I had a melt down then I'd have a good story to post about, like how the whole architecture melted into a hole and was now at that moment, moving to the center of the Earth.

That would be cool!

I'm surprised to see this talk about fanaticism or extremism entering the realm of software development. Especially Bob Martin, who your are saying, is the "most notorious TDD extremist". I'm getting the picture of someone with a black bag on his head and waving a machete. If Bob is going around and chopping off the heads of developers for not doing TDD then that's too bad. There was once a project where the entire team was doing TDD except for one guy. People were getting fed up with him but all we did is ask that he be removed from the project. I didn't know there were people running around with machetes.

And Bob is the most notorious? Does the FBI have him on a list? Here I thought he was just a software developer who was trying to get people in alignment on good engineering practices. I didn't know he was a ring leader of people who strap bombs to their chests and blow up cafes. Are you really sure about this?

I'm glad I'm not a TDD extremist since you say that their job description is for writing stack classes and going to conferences. That's way less interesting than writing multi-tiered enterprise applications. Also I don't have any of the right equipment like a machete or a black bag that fits my head. (Unless having a snowboard and a helmet counts.)

I like bullet 2 in the "rules of thumb". If followed correctly, that means you are doing TDD.

Here are comments on the other bullets:
******
I don't agree with bullet 1 because you will develop more tests if you write them first. Perform some TDD by pairing with a good practitioner and I know you will agree. I recommend Bob Martin, but be sure to have Homeland security around in case he gets all extremist.

Bullet 3 -- YAGNI is a very useful tool for preventing people from spiraling to complexity. People who don't like YAGNI probably don't like working with someone who says they're design is more complex than necessary. If you work with others and can't justify the strange, super-fly architecture you want to build, then you won't like YAGNI.

Bullet 4 isn't on the mark. The only thing that matters to your users is that the application is useful. This also implies that the application is of sufficient quality so you aren't wasting their time. Unit testing as well as functional testing are ways to achieve this quality. Unit testing will scale to far more code coverage than functional testing. So unit testing is very important too.

Bullet 5 -- You should feel bad if you are developing low quality code. Don't worry, you'll still find places that figure if you can write code, you can make quality someone else's problem. If you practice TDD, you are addressing quality as soon as possible. You are also doing testing as soon as possible (bullet 2, remember). As far as the comment about where TDD is a bad fit, there aren't many.... TDD is harder to do in some circumstances than others. The biggest circumstance is where an architect/developer is trying to make something more complicated than it has to be, or they are mixing concerns by writing super big methods, or they are coupling their code to other classes instead of writing nicely decoupled code. Yes, TDD forces you to architect better and some people don't like to do that. They'd rather do it their way and throw the code over the wall to make it someone else's problem.

Another common misconception (I'm not sure if you share this one) is that TDD means writing a slew of tests first. This is a violation of YAGNI. You write the simplest test first, then write the simplest piece of code to make it pass, then start back writing a new simplest test. About three tests in, you have some pretty sophisticated code. You keep at it, and after a while, you are done. :-)

I look forward to your future posting on Pair Programming Conspirators.

Lance Kind
Practicing TDD since 1999
Extremist free since 1970
Spin Free since ????

I don't know Jim Coplien. He sounds like a smart guy since it says "software guru", so that means I'm inclined to listen to him. For C++ books, I'm more of a Scott Meyers fan myself. The problem is that I must be doing YAGNI/TDD incorrectly because none of my projects have melted down in iteration three. What I'm most disappointed in is that Jim says it will be an architectural "melt down". In my experience, the worst cases have been that I have to do some refactoring and that is nothing on par with "melt down" which brings to mind Chernobyl or the China Syndrome. If I had a melt down then I'd have a good story to post about, like how the whole architecture melted into a hole and was now at that moment, moving to the center of the Earth.

That would be cool!

I'm surprised to see this talk about fanaticism or extremism entering the realm of software development. Especially Bob Martin, who your are saying, is the "most notorious TDD extremist". I'm getting the picture of someone with a black bag on his head and waving a machete. If Bob is going around and chopping off the heads of developers for not doing TDD then that's too bad. There was once a project where the entire team was doing TDD except for one guy. People were getting fed up with him but all we did is ask that he be removed from the project. I didn't know there were people running around with machetes.

And Bob is the most notorious? Does the FBI have him on a list? Here I thought he was just a software developer who was trying to get people in alignment on good engineering practices. I didn't know he was a ring leader of people who strap bombs to their chests and blow up cafes. Are you really sure about this?

I'm glad I'm not a TDD extremist since you say that their job description is for writing stack classes and going to conferences. That's way less interesting than writing multi-tiered enterprise applications. Also I don't have any of the right equipment like a machete or a black bag that fits my head. (Unless having a snowboard and a helmet counts.)

I like bullet 2 in the "rules of thumb". If followed correctly, that means you are doing TDD.

Here are comments on the other bullets:
******
I don't agree with bullet 1 because you will develop more tests if you write them first. Perform some TDD by pairing with a good practitioner and I know you will agree. I recommend Bob Martin, but be sure to have Homeland security around in case he gets all extremist.

Bullet 3 -- YAGNI is a very useful tool for preventing people from spiraling to complexity. People who don't like YAGNI probably don't like working with someone who says they're design is more complex than necessary. If you work with others and can't justify the strange, super-fly architecture you want to build, then you won't like YAGNI.

Bullet 4 isn't on the mark. The only thing that matters to your users is that the application is useful. This also implies that the application is of sufficient quality so you aren't wasting their time. Unit testing as well as functional testing are ways to achieve this quality. Unit testing will scale to far more code coverage than functional testing. So unit testing is very important too.

Bullet 5 -- You should feel bad if you are developing low quality code. Don't worry, you'll still find places that figure if you can write code, you can make quality someone else's problem. If you practice TDD, you are addressing quality as soon as possible. You are also doing testing as soon as possible (bullet 2, remember). As far as the comment about where TDD is a bad fit, there aren't many.... TDD is harder to do in some circumstances than others. The biggest circumstance is where an architect/developer is trying to make something more complicated than it has to be, or they are mixing concerns by writing super big methods, or they are coupling their code to other classes instead of writing nicely decoupled code. Yes, TDD forces you to architect better and some people don't like to do that. They'd rather do it their way and throw the code over the wall to make it someone else's problem.

Another common misconception (I'm not sure if you share this one) is that TDD means writing a slew of tests first. This is a violation of YAGNI. You write the simplest test first, then write the simplest piece of code to make it pass, then start back writing a new simplest test. About three tests in, you have some pretty sophisticated code. You keep at it, and after a while, you are done. :-)

I look forward to your future posting on Pair Programming Conspirators.

Lance Kind
Practicing TDD since 1999
Extremist free since 1970
Spin Free since ????

Somebody commented that TDD is not a silver bullet. That may be true, but it's interesting to note that during OOPSLA last year, there seemed to be general agreement that it is probably the best approximation of a silver bullet, compared to all of the other tools and mechanisms that claimed that title over the course of the last 50 years.

Check out Brian Foot's talk on Big Balls of Mud (www.laputan.org/) and some footage of the panel discussion at Youtub (www.youtube.com/watch?v=Z-1X3duvryA)

I believe that what was said at OOPSLA was that good OO design/practice/code, not TDD, was closer to a silver bullet than all other things that have made a claim on the title.

I'm a believer in TDD because I think that it helps drive better OO designs & code.

-Robert

TDD as micro-design Driver.

Hi Cedric.
I saw this post and your presentation at QCon.
I guess there is not discussion about to use or not to use TDD, but there is one about TDD being a required solution to all projects, or if it is a silver bullet or not.

Frankly, I rather take a good idea and analyze it for great and weak points. TDD, as you mention, may be not that bad after all if used in the correct place, at the correct time, and those are not everywhere, everytime.

I see three actual momentums of development, that generate three designs (each one in its own level): Strategic (Architectural) design, Tactical Design and Operational Design (Design at development). In one of my posts (acoscomp.com/wblog//index.php/a/2008/03/23/tdd_or_not_tdd) I expose the use of TDD as a good methodology for the last one, but not actually for Tactical nor strategic design.

That is, we shouldn't buy TDD or discard it, I guess we can incorporate it to our development cycle, if used correctly and at the correct level, in a way it wont melt anything important.

William.

My team uses TDD to create life-critical medical applications. Either you have offended me by implying that this is a "toy application" or you are grossly misunderstanding, unimaginative, and/or unpracticed in the real concerns and practice of TDD.

Telling people to focus on the release and that they don't have to feel bad for not worrying about quality up front (which is, in fact, what you have done) is akin to spreading malpractice.

ps your comment submission form could have used some testing of any kind, as I have had to significantly edit relevant words.

Test driven design does not replace specifications or architecture. On many projects I have saved the project by looking ahead and developing what's needed from an architecture standpoint rather than what was strictly needed from an end-user standpoint. When you are building a house, do you only build what the owner asks for (if they forgot to ask for a foundation, you don't provide one) or do you provide what they requested plus everything else that you know is needed for building a solid house that follows building codes? problem for most software development projects is that there are no building codes.

Testing is nothing more than taking a sample. It does not prove that your code is working correctly. It actually doesn't even proof that the particular scenario you tested works correctly. It just shows that at the time you executed the test you observed the described results. With a black box there is always the possibility of non-deterministic behavior, and thus your test outcomes are not guaranteed to be repeatable.

So, TDD has it's place. But TDD is not an excuse for developers not to learn more than just coding. I have seen way too many developers who can write code (as in that they know a programming language), but that's about where it stops. Just view sofwtare development as an engineering discipline and pick the tools and methodologies appropriate for the job. If TDD fits that, great, if not, also great.

Just sounds like people are trying to be argumentative.

Tests are not test, but more of a design document. Their purpose is not only to demonstrate to "debuggers" the purpose of the code, but to also document behaviors. Developer's should not be writing for every caveat, but more of general behaviors.

With that in mind 80% of this article's and comments arguments don't apply.

I don't feel the author and many of the people commenting have taken a real look at what TDD's original intent was.

Although it could also be the speakers are taking it in a direction, it wasn't intended in the first place.

We use TDD is a global engineering application and it fits great. I'd like to hear what real world applications it would not fit into.

Typically we develop the Use Case and Sequence Diagrams and develop Test's from them. And it works very well.

My thoughts,
Nick