Are the tests themselves excluded from the revert step? Otherwise I’m not sure how we can get the option of writing a failing test first, then making it pass, which I’ve found a quite useful idea from TDD. Without that, it doesn’t seem like we can use this in good faith to write new projects or new features, because we’d just write code without ever writing tests.
I’m trying to distill this question down to something where Beck’s answer wouldn’t be “you’re doing everything wrong and that’s why this hurts”. Like, say I have some existing code and in my main function I group several distinct interfaces together. I now want to add a new interface that does a new thing to this group. What are the steps to work on that in this flow? In TDD I might write a suite of failing tests that probe the interface of my new thing and make them pass one by one. What would I do here?
In general, the approach in TDD is to write each test right before passing it rather than writing a bunch upfront and passing them later. There’s been a lot of variation of practice but that’s the way it’s been among people directly influenced by Kent’s formulation since he started describing it in the late 90s.
I communicated poorly; what you describe is what I do when I do TDD (having learned it from the horse’s book, so to speak), but before I start writing any code I think about the interface I’m going to write and what tests I’d eventually like to have, and then do Beck’s cycle one-by-one on those.