Big fan of breaking a test to ensure I'm testing what I think I am. Great way to avoid false positives without having to write your tests first/ follow Test Driven Development, which I've always found tedious. Thanks for eloquently putting this process into words!
Apologies if I am missing something here, but in your example, assuming you wrote your test first and it initially failed because there was no implementation and then you added the same implementation you wrote earlier and the test (without the await) passed, haven’t you ended up in the same place (false positive test)?
I fully agree the idea that you need to see a failing test, but don’t you still have to prove to yourself that the test is failing for the reasons you expected it to fail?
In the case of a subtle bug in the test like this one, does test first really address the problem?
Thank you, you have raised an important point, Krishna. You found a weakness in this essay. Seeing it failing for the right reason is important. The simple example assumes that developers will write the following code first before implementing it.
const newFeat = async () => {};
Now I ponder if an alternative approach to test last can catch the false positives.
I've edited the essay, but now I think a developer can also forget to write something minimally with the test-first approach plus seeing it fail for the right reason. It proves the test-first approach is no silver bullet for the false positive, as it requires discipline.
Big fan of breaking a test to ensure I'm testing what I think I am. Great way to avoid false positives without having to write your tests first/ follow Test Driven Development, which I've always found tedious. Thanks for eloquently putting this process into words!
My pleasure, thanks Chris!
Apologies if I am missing something here, but in your example, assuming you wrote your test first and it initially failed because there was no implementation and then you added the same implementation you wrote earlier and the test (without the await) passed, haven’t you ended up in the same place (false positive test)?
I fully agree the idea that you need to see a failing test, but don’t you still have to prove to yourself that the test is failing for the reasons you expected it to fail?
In the case of a subtle bug in the test like this one, does test first really address the problem?
Thank you, you have raised an important point, Krishna. You found a weakness in this essay. Seeing it failing for the right reason is important. The simple example assumes that developers will write the following code first before implementing it.
const newFeat = async () => {};
Now I ponder if an alternative approach to test last can catch the false positives.
I've edited the essay, but now I think a developer can also forget to write something minimally with the test-first approach plus seeing it fail for the right reason. It proves the test-first approach is no silver bullet for the false positive, as it requires discipline.
Thanks a lot for the challenge!
Most welcome!
Personally, I don’t trust my tests until I’ve stepped through them 😉