> The tests are an executable to-do list that guides development
So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).
> Provides a record of the experimentation taken to accomplish a goal
If you're doing a proper refactor cycle, those tests will vanish (or change) as the code evolves. You're back to relying on your source control, which provides the benefit with or without tests.
There are benefits to TDD; these two are not among them IMO.
> So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).
I don't necessarily use tests as a todo list like gkop, but for me at least... my first tests usually come from acceptance criteria if available, or some sort of business requirements. They usually end up being my feature or integration tests.
So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).
> Provides a record of the experimentation taken to accomplish a goal
If you're doing a proper refactor cycle, those tests will vanish (or change) as the code evolves. You're back to relying on your source control, which provides the benefit with or without tests.
There are benefits to TDD; these two are not among them IMO.