My comments on “religion” in this industry has more to do with … leadership style. Tony is really good at coming up with existing names for the ideas that I have, and has told me that what I’m trying to convey is known as “Falling into the pit of success.” I’ve always found that if you want someone to do something, the best thing is to make it easy for them. I don’t consider it coddling, but rather subtle coercion.

First off, there are not many good teachers out there. But there are a lot of loud people. Just as with religion, I would differentiate between Bible thumper and apologists. I strive to be an apologist. But I also see the need to be confrontational from time to time.

Not all of my best teachers were the coddling type. Some of them were confrontational. They did this just to get the thought processes flowing. It doesn’t work for everyone, but it does work. I know lots over VERY good preachers who do just this.

As you know, making people better developers is more than TDD. Much more. TDD all by itself wont magically make people better, but TDD alongside better practices often start the process.

Which leads to one of my personal items: always be improving, always be learning. At no point should you be satisfied with where you are.

My current policy on unit tests is to test the tricky code, and the important code, and to write tests as issues become apparent. Worse than a bug is a regression bug…

I am not overly familiar with BDD – I’m still trying to figure out what the difference is. I must research further.

“Also, a bad architecture, or bad testing methodology can be a major drain on productivity. Which gets to what some of your point is really after, which is:
“show me TDD done well, and then I’ll believe you.””

I think you hit the nail on the head with this paragraph. A bad design, or a bad test can be worse than no design or no test at all. I think a lot of people have had bad experiences with unit tests, get frustrated, and write it off as useless. Hence, friction.

I’ve been contemplating putting together an example application using MVC, and some of the things I’ve been learning by using LTS in my last 3 projects. Making this easy to test would be one of the primary goals of the assignment for myself. Of course, as you said, it’s hard to find time…

Finally, it is my priority to have working software too… I tend to be a perfectionist about that too… but it really comes down to the priorities of who is paying the bills.

Good discussion,
~jw

My definition of done is the client is either happy with the software or out of money (this usually comes from change request — ie. “I know that was what I wanted then, but this is what I want now”).

My question on “fully tested” was in response to experience in teaching TDD. Contrarian developer tend to look at TDD and say you are not done until every little edge case is accounted for for every class (which is impossible). Also, we are in agreement with TDD. It is test first, and Test Driven Design.

Side note: this is one reason I like the notion of BDD (Behavior Driven Design). You are validating the behavior is correct. Less on the notion of testing.

Also, a bad architecture, or bad testing methodology can be a major drain on productivity. Which gets to what some of your point is really after, which is:
“show me TDD done well, and then I’ll believe you.”

Which gets much harder, because few of us are working on open source, and none of us have time to setup sample applications. Although, CodeCamp Server is supposed to have some very good unit test metrics.

Finally, on the reputation part. That really comes back to priorities — which are really a company policy more than a personal preference. My priority is for tested, working software. I would rather be a bit late than release a bug.

This can also get back to what type of software you are writing. If it is accounting software…no one can afford a money bug. That has to work the first time.

I could guess that The Dude would know he was done when he finished integration and acceptance testing.

No amount of unit tests can tell you you are done or even that your system works, only that the code you have written functions as you think it should.

I for one would like to hear a better answer to the original question, if all there is to offer is “your code sucks because you don’t test” then I’m not sure I’m sold either.

I’m trying really hard to be nice about this, but I’m really tired of hearing this cliché. There are many forms of testing; what I thought I was discussing was unit testing and TDD in particular. There are many ways to know you are done – when the client is happy is the one I usually go by.

“Also, I believe that if you really don’t want to use interfaces because you don’t consider test code to be a first class citizen.”

You’re absolutely right. I don’t consider test code to be a first class citizen. I doubt many people would disagree with me if I said it is a bad thing if your production code had a dependency on your unit test DLL. That to me makes it less than a first class citizen – if it were to suddenly disappear, your customers wouldn’t know the difference. I’m not claiming that it’s not important, however.