[pmarreck]

> writing code takes double the time when you also have to write the tests

this time is more than made up for by the usual subsequent loss of debugging, refactoring and maintenance time, in my experience, at least for anything actively being used and updated

[tsimionescu]

Yes, if you were right about the requirements, even if they weren't well specified. But if it turns out you implemented the wrong thing (either because the requirements simply changed for external reasons, or because you missed some fundamental aspect), then you wouldn't have had to debug, refractor or maintain that initial code, and the initial tests will probably be completely useless even if you end up salvaging some of the initial implementation.

[twic]

No, that's a separate issue, that eschewing TDD doesn't help you with.

With TDD, the inner programming loop is:

1. form a belief about requirements

2. write a test to express that belief

3. write code to make that test pass

Without TDD, the loop is:

1. form a belief about requirements

2. write code to express that belief

3. futz around with manual testing, REPLs, and after-the-fact testing until you're sufficiently happy that the code actually does express that belief

And in my experience, the former loop is faster at producing working code.

[ipaddr]

It usually works out like..

  form a belief about a requirement
  write a test
  test fails
  write code
  test fails
  add debug info to code
  test fails no debug showing
  call code directly and see debug code
  change assert
  test fails
  rewrite test
  test succeed
  output test class data.. false 
  positive checking null equals null
  rewrite test
  test passes
  forget original purpose and stare at green passing tests with pride.

[xxs]

> add debug info to code

On a more serious note: just learn to use a debugger, and add asserts, if need be. To me TDD only helps having something that would run your code - but that's pretty much it. If you have other test harness options, I fail to see the benefits outside conference talks and books authoring.

[pmarreck]

my professional opinion is that having to resort to a debugger is a bad-design, bad-testing code smell

[laserlight]

Yes, so much this. I don’t really understand how people could object to TDD. It’s just about putting together what one manually does otherwise. As a bonus, it’s not subject to biases because of after-the-fact testing.

[pjmlp]

Test the belief of recovery from a network split in distributed commit.

[laserlight]

I don't get the point. Is it something not testable? If it's testable, it's TDD-able.

[pjmlp]

TDD sales pitch is not to write any code without an existing test.

[minimeme]

That's my experience also! It's all about faster feedback and confidence the tests provide.

[thrwyoilarticle]

>at least for anything actively being used and updated

This implies that the strength of the tests appears when it's modified?

Like the article says, TDD doesn't own the concept of testing. You can write good tests without submitting yourself to a dogma of red/green, minimum-passing (local-maximum-seeking) code. Debating TDD is tough because it gets bogged down with having to explain how you're not a troglodyte who writes buggy untested code.

And - on a snarkier note - this is a better argument against dynamic typing than for TDD.

[wenc]

In theory, I agree. In practice, at least for my projects, the results are mixed.