[luhn]

>> if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. > Well, first of all, that's not TDD. TDD is Test-Driven Development. In your scenario, you wrote the test after the code in question. In TDD, the whole point is to write the test before the code in question

It's a regression test, which is definitely TDD. The code in question is the fix for the bug, the test verifies that the bug is fixed and will remain fixed.

[tokenizerrr]

No that is just regular testing. TDD is about writing tests first, before other code.

[richardknop]

Well, that's exactly this case. You would write a test to replicate/prove the bug and then - afterwards write the code to fix the bug, no? So you would write tests first.

[tokenizerrr]

But the code containing the bug is already there. The idea of TDD is that you write tests verifying behavior before there is any code.

[ZoFreX]

This definition of TDD either supposes that it is possible to write software with zero bugs using TDD, or that your project ceases to be TDD as soon as a bug is discovered, or any other change is required. I propose this definition is not very useful.

[tokenizerrr]

I see that as just writing regular unit tests, business as usual. Not TDD, still very useful.

[richardknop]

If you are writing something from scratch yes. But if you inherited a codebase written by somebody else who didn't to TDD so there are no tests, you can still use TDD for refactoring.

So any new changes/bugfixes you will make to this legacy codebase, first you will write a test and then make change. That's pretty standard. Many legacy codebases will have no tests and people who wrote the code will have left long time ago.