Okay, I think I see where you’re going, but let me double-check:
You’re saying that false positive tests are weeded out in TDD because the implementation isn’t allowed to have any code to raise errors or return negative states until there’s first a test checking for those errors/states.
So, if an everythingWorkingOkay() function always returns true, it wouldn’t pass the test that breaks things and then makes sure it return false. We know that test exists because ideally, for TDD, that test must be written before any code can be added to the function that is intended to return false at all.
Whereas, if the programmer writes the code first and the test second, they might well forget to test for negative output, since that possibility won’t come to mind as readily.
Okay, I think I see where you’re going, but let me double-check:
You’re saying that false positive tests are weeded out in TDD because the implementation isn’t allowed to have any code to raise errors or return negative states until there’s first a test checking for those errors/states.
So, if an everythingWorkingOkay() function always returns true, it wouldn’t pass the test that breaks things and then makes sure it return false. We know that test exists because ideally, for TDD, that test must be written before any code can be added to the function that is intended to return false at all.
Whereas, if the programmer writes the code first and the test second, they might well forget to test for negative output, since that possibility won’t come to mind as readily.
See this other reply for more detail.