* Faster development feedback loop by minimizing manual interactions with the system
* The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is
* Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborate on work-in-progress
If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.
This is fine, if your already have a fair idea of how to architect your problem. But if you don't, it makes it harder to refactor your interfaces (in the same way that clients depending on your interfaces does). Of course, you can rewrite the tests, since you have control over them; it's just harder. And you don't have the TDD raison d'etre reassurance of working tests for this refactoring, of interfaces. Higher level function tests, yes; unit tests, no.
Which means the system design must be obvious enough that you have well defined lowly coupled units in the first place.
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.
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.