Agreed, it is a social problem and while technology will never cure a social problem completely, the right tools can help by making it more difficult to cause the problem than to fix the original issue.
I give the example of Aegis because it provides/imposes a development process designed to alleviate just this situation. In the case of a single developer disabling a test, this would be stopped at the next stage of the process which is a review. Aegis won’t allow the change-set to progress through to a repository commit until the review is passed.
This means that at least two or more people (developer and reviewer) have to agree to knowingly sabotage the project by omitting the test.
If a development team has reached at point where testing has become this expendable then it has a far greater problem than a single bug being introduced.

Scott

It would be great if folks wouldn’t confuse the two.

Just in case it’s not clear, TDD refers to the practice of using tests to drive development. You don’t write a line of code without a failing unit test. This means you write your tests before you write the code. This has several benefits, including 1) being much more interesting than writing tests afterwards, which I find mind-numbing, 2) forcing you to define your interface before you start coding, 3) reducing feature-itis, where you might add stuff “just in case,” and, oh yes, 4) ensuring greater test coverage.

Clearly, gojko’s post is about testing in general, not TDD.

///ark

Maybe you could add one last point:

== Developers think that TDD is only about Testing ==
There is much more to TDD than testing. First of all, in TDD you write the test *before* you write the code.
If you’re not doing that, you’re not doing TDD. Second, the rythm between writing a test and production code
should be under a minute (never more than a couple of minutes). And third, you should never write any production
code until you have a failing test.

Most developers failing with TDD are ignorant of these guidelines.

1 is a human problem, not a code problem. No integration system is going to prevent a developer from commenting out the offending verification line, which is what happens most often.