[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.