In blog-post-beyond-tdd Liz Keogh makes a fascinating argument that perhaps we can go right from spiking to stabilizing, as opposed to following the more traditional spike, throw away, then test drive approach.
Seems related to At 47 Noel Rappin says that writing code in small pieces is more important than doing TDD, and points to cut back and Erich Gamma's essay where they are doctrinaire about writing code in small pieces, but not necessarily about writing the test before writing the code. (#)
is the only real difference about spiking not doing tests while doing it?
what happens to the process of spiking when you do it well (refactoring, using good coding practices). Does it lose some of its utility?
0038 tdding spikes away with rebase
watched. Skeptical that this is a good idea. He encourages us to try it out at the end, but mainly to learn more about TDD and version control, not because he thinks it's a good idea. His concern about the idea is that it would lead to your spiked design influencing your TDD design too much. (#)
From a comment in hacker news: "
Going from prototype to tested code is possible. Here's how I'm doing it, for command line tool that provides local development environment for remote Kubernetes cluster (https://datawire.github.io/telepresence/): 1. Build prototype, test manually. 2. Have coworkers try it out. 3. Fix UX based on feedback, test manually. 4. Once initial UX was nailed down, write end-to-end tests. Beyond adding features, next I will rewrite the core using test-driven development (TDD), so that the internals are maintainable. and the end-to-end tests will ensure the basic functionality continues to work. The UI is fairly simple, and at this point I have confidence that it won't change multiple times in a day, so it's worth the effort to stop relying solely on manual testing and write some automated UI tests." (#)