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.> 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.
my professional opinion is that having to resort to a debugger is a bad-design, bad-testing code smell
Re:I have complicated feelings about TDD
by laserlight on Thursday August 18, 2022 @03:34PM
(#32513911)
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.
Test the belief of recovery from a network split in distributed commit.
Re:I have complicated feelings about TDD
by laserlight on Thursday August 18, 2022 @06:49PM
(#32515759)
I don't get the point. Is it something not testable? If it's testable, it's TDD-able.
TDD sales pitch is not to write any code without an existing test.
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.