Right! Having to go back to code you've written for days to find the right test cases definitely seems time wasteful to me, but what if one does a test-last approach with very small cycles of implementing then testing (instead of testing everything when your "done")? Do you suppose that would take any longer than TDD?
As long as you keep your testing cycles short and crisp, I assume there won't be a noticeable difference.
But...
... I think there is still one important difference. When doing TDD (meaning test-first), there is, at least in my opinion, a hugely underrated step saying
Write a test and watch it fail
For me, this step is essential. Watch the test fail. It's the only way to validate that
you are about to write code that is in fact needed.
you made the right assumptions while writing the tests
you implemented your test correctly
When doing "test-last", you are losing these advantages. So in the end, your assumptions might have been wrong for a couple of test cases and that can slow you down as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right! Having to go back to code you've written for days to find the right test cases definitely seems time wasteful to me, but what if one does a test-last approach with very small cycles of implementing then testing (instead of testing everything when your "done")? Do you suppose that would take any longer than TDD?
As long as you keep your testing cycles short and crisp, I assume there won't be a noticeable difference.
But...
... I think there is still one important difference. When doing TDD (meaning test-first), there is, at least in my opinion, a hugely underrated step saying
For me, this step is essential. Watch the test fail. It's the only way to validate that
When doing "test-last", you are losing these advantages. So in the end, your assumptions might have been wrong for a couple of test cases and that can slow you down as well.