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