The “Specification driven development” post mentions the idea of a “a low-resistance workflow” that can be achieved with test-driven development.
Overall that post is probably a bit dogmatic and over-eager about the idea of test-driven development, but the point about achieving a low-resistance workflow still seems valuable.
A more trivial way of doing that is to use a simple workflow like this:
- Do you have a failing test? -> Make the test pass.
- No failing test? -> Make a failing test case.
A lot of the time, no further thought is required. This is a simpler distillation of the idea of a low-resistance workflow. There is rarely a hard decision to make, and you can keep moving forwards by doing either 1. or 2. in a loop.
I also find that leaving a failing test case is a good state to leave a project in so that it’s easy to come to back to later. The failing test case will highlight exactly what needs to be done next to get back into the flow.