?
Given the original question where the poster is catching up with his legacy code, which implies no experience doing TDD, the Saff's technique seems to be overkill that discourages getting started.? Keep it simple until enough experience?is gained to warrant getting more sophisticated.
I'm surprised by this framing. I don't know what the Saff Squeeze has to do with experience with TDD. The Squeeze doesn't care whether you've written the test first nor whether you're doing evolutionary design. The only novel part is learning what "inline" means in this context.
The entire technique is "write a failing test, then (inline & prune dead code) until you can spot the cause with the naked eye". That sounds pretty simple to me. I don't see what's sophisticated in it. Indeed, the whole point is that it's mechanical and easy to learn, if tedious, compared to the delicate heuristics needed to step through code with a debugger; decide when to step over, step in, or step out; judge which variables to watch and how closely; and decide when enough is enough. *That* seems sophisticated to me.
--
J. B. (Joe) Rainsberger :: ?:: ::
?
On Tue, Mar 29, 2022 at 9:16 AM Alan Baljeu via <alanbaljeu=
[email protected]> wrote:
This looks like a useful method.? Another approach I learned as the Mikado method:?
1. Write a failing test.
2. Change the code to pass it.
3. If you can't _simply_ do this, then:
a. identify where you get stuck
b. revert
c. refactor so you're not stuck, and goto 1 (or 2).
In the context to match Saff's technique, the refactoring would slowly expose the heart of the troublesome code until the problem is identified and solved.? That said, I can see Saff's route may be more efficient at times.? It especially looks useful if the problem ultimately lies in a 3rd party's library and you need to send a small failing test for them to fix your problem.
On Monday, March 28, 2022, 05:28:05 p.m. EDT, Rodolfo Carvalho <
rhcarvalho@...> wrote:
Hi Alan,
On Mon, Mar 28, 2022 at 7:54 PM Alan Baljeu via <alanbaljeu=
[email protected]> wrote:
I'm confused by language in that post.? I think "commit" means locally post to Source control your newly changed code.??
[...]
- > A) Maybe squash all these commits, [...]
In other words, delete the commit and TDD a new test which we make pass.
- > B) Throw away all those commits, then test-drive the missing behavior using the notes [...]
In other words, delete the commit and TDD a new test which we make pass.
Do you see my confusion?
I see how this can be confusing.
The difference is in case A you don't simply "delete" commits, "squashing" means you replace several commits with a single commit that applies the same patch as all the previous commits together.
In this case, you accept that you're done and change history for the sake of having a clean history without the step-by-step commits.
Conversely, in case B you indeed throw away commits, and rely solely on the fresh knowledge to do it all again. You may or may not end up with the same patch as in case A.
Cheers,
Rodolfo Carvalho
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
J. B. Rainsberger