code_of_the_damned();

• TDD keeps your developers focused on solving the immediate problem, by adding one feature at a time.
• This can lead to less actual production code being produced when TDD is used.
• You're software will be testable
• These tests will give you confidence when entering system integration.
• Yes, your development phase may take a little longer.
• However, you will have confidence during system integration to make changes, and detect if it affected your system negatively.
• This will make your overall schedule more predictable, and should shorten the length of the system integration phase.

This is not a situation that is unique to TDD, it is possible with any process that develops any type of regression test system.

• Your tests may be too complex.
• Your code is tightly coupled, and your programming side-effects are interfering with this other code.
• The other developers delivered code with broken tests.
• The length of your Integration cycles are too large.

• Write simple tests so they will be maintained.
• Before you make any changes, compile your source to verify you are starting with a clean build.
• Even if you need a large amount of time to complete a task, you should still rebase with the developer stream often.

Ok, hold on.

One needs to read the entire entry to first gain the context, then read the conclusion that he has reached and why. He explains that he adopted TDD, and it taught him some things, but now he prefers to simply perform system tests. Because TDD creates horrible designs.

Let's address a few issues that David raises in this entry. You state the issues, and I will respond.

I want to address something with this statement. It seems that there are many different groups of technology and process advocates professing the true way to develop.

Again, there is no silver bullet.

What works for one development group, may not work for another; it may not even be possible or appropriate to try to apply the prescribed method in all situations.

I posit that if you simply start coding, without tests, you will also "give birth to some truly horrendous monstrosities of architecture." TDD does not alleviate you from performing any of the common steps in the software development process. The one truth stated in the entry above about TDD is:

"avoid doing anything that's 'slow'. Like hitting the database. Or file IO. Or going through the browser to test the whole system."

TDD stands for "Test Driven Development", not "Test Driven Design". You should have an overall picture of what your design and architecture should be to accomplish your goals.

TDD is a process to help direct the development to produce code that is testable, correct, robust, and complete by providing feedback quickly during development.

That is correct.

And, these unit-tests become regression tests during system integration. Now they are used to defect if changes that are made during system integration break a feature that previous existed.

There are very few tools that exist today that find bugs. These tools are designed to look at specific things that are common sources of errors, such as memory management.

I don't want to stray too far from TDD. However, unit-testing is a fundamental part of TDD.

Let's look at the context and reasoning for a few of the arguments presented in the paper.

Those are some strong words, and I couldn't agree more. Testing for code coverage is a misguided endeavor that only provides a false sense of security.

All tests should provide value. If a test does not provide value, it should be removed.

Code coverage is another metric that can be used to evaluate code. However, this metric alone does not indicate how well a unit is actually tested.

I like this statement: "automated crap is still crap."

Most of this paper presents justified arguments. However, this section appears to be the author's opinion rather than fact.

I believe that unit tests for the sake of unit tests is bad; similar to my thoughts on the code coverage metrics for tests. If a test provides value, then it is good. If you end up with more valuable test code that production code, this says nothing about the developer or the code. Hopefully the tests were well designed, and the production code is flexible and robust.

There is no coupling between the Test code : Production Code ratio. Again I posit, the same developers that created an inflexible and low-quality system with too many tests, would create the same quality system with only using system-level tests.

I have not read that paper by, Janzen and Saladin. It sounds interesting. If I can get access to it, I will read it and get back to you. Or if you read it, let me know what it says.

Otherwise, tests do not need to be that tightly coupled to the code. Furthermore, if you find that they are that coupled, and you need to ship them with your product, you are doing something wrong.

Yes, unit tests will be associated with a module, and there may be stubs, fakes and mocks to help verify that module. However, the code in that module should not change in order to be in a "test mode".

The point is to verify the code the way it will be run in production is correct, not to create tests that pass.

It looks like we are starting to digress into a discussion about unit testing in general.

Let's save that for another time.