The author is complaining that they don't know their problem space, their solution approach, and they need to do some exploratory programming to figure it all out.
Fine. Do that.
Once you've done that, you're ready to develop. Now you're ready to apply TDD if you so desire. I prefer what I call Maintenance Driven Development, which I discussed years ago on my blog: https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...
>However, very few developers follow this approach religiously
I do it pretty religiously. There are 3 exceptions:
1) I'm doing a spike (i.e. what author calls exploratory code) in which case, probably this code is getting disposed of. This is the one main exception.
2) I'm just tweaking a config value/printed message/something else surface level.
3) The cost of building test infrastructure is prohibitive (if it's a long running project I will aim to keep building that infra until it is possible though...).
That's it. As far as I can tell there arent other scenarios where it isnt a good idea.
I prefer to think of it as “test before commit” or “test before push”.
If I create a pull request with well written code and tests to match, and you can’t tell which came first, the code or the tests, it doesn’t matter in what order they were created.
TDD is Test Driven Development.
The author is complaining that they don't know their problem space, their solution approach, and they need to do some exploratory programming to figure it all out.
Fine. Do that.
Once you've done that, you're ready to develop. Now you're ready to apply TDD if you so desire. I prefer what I call Maintenance Driven Development, which I discussed years ago on my blog: https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...
>However, very few developers follow this approach religiously
I do it pretty religiously. There are 3 exceptions:
1) I'm doing a spike (i.e. what author calls exploratory code) in which case, probably this code is getting disposed of. This is the one main exception.
2) I'm just tweaking a config value/printed message/something else surface level.
3) The cost of building test infrastructure is prohibitive (if it's a long running project I will aim to keep building that infra until it is possible though...).
That's it. As far as I can tell there arent other scenarios where it isnt a good idea.
Make some generalizations about a process and omit the obvious solution as pointed out in the comments is a good way to get some engagement.
I prefer to think of it as “test before commit” or “test before push”.
If I create a pull request with well written code and tests to match, and you can’t tell which came first, the code or the tests, it doesn’t matter in what order they were created.