I think TDD helps or doesn't help depending on the circumstances. The problem is the people who claim there's One True Way.
For instance, 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. But if you're starting a new project from scratch with loose requirements, or worse yet, building a prototype, starting with tests would be a waste of time at best.
> 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.
So the value in your scenario is only insofar as the test is a useful way to quickly exercise the code in question. For example, if we have some sort of customer-facing website and there is a bug in how they save their user profile, it will be easier to test fixes to the problem if we don't have to go through the full flow of logging into the site, navigating to the profile, making edits, and clicking save all the time. But having an XUnit-style framework for running that test is not necessary for that.
>> 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.
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.
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.
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.
It's adopting test driven development during maintenance of an existing system. It's exactly TDD (identify need, write failing test, code to pass test.) TDD is a discipline that can be adopted at any time, not an SDLC that can only sensibly be adopted at the initiation of a project.
It's TDD. Just because the whole app wasn't developed with TDD doesn't mean you can't test drive a bug fix.
There's a bug, you write a test, "this bug shouldn't exist", that test currently fails, then you write just enough code to fix the test, then refactor. That's TDD.
Exactly what I was thinking. The test ends up being written firs this case, before you write/edit the code to fix the bug. So it falls under strict definition of TDD.
For instance, 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. But if you're starting a new project from scratch with loose requirements, or worse yet, building a prototype, starting with tests would be a waste of time at best.