On Tue, Mar 29, 2022 at 4:51 PM Avi Kessner <
akessner@...> wrote:
?
Thanks all more clear now.?
We want to do a copy/paste inline.
The difference being that the IDE will delete the original function when inlining, not make an inlined copy.
I realized later that you might have meant this. I don't use the words this way, so I didn't grasp the difference immediately.
IntelliJ IDEA, for example, doesn't assume that "inline" means "...and delete the original". You have to decide that when you inline a function.
Indeed, I meant what you're calling "copy/paste inline": inline only this invocation without deleting the original function. The Saff Squeeze would destroy the production code otherwise.
--
J. B. (Joe) Rainsberger :: ?:: ::
?
On Tue, 29 Mar 2022, 21:40 J. B. Rainsberger, <
me@...> wrote:
On Mon, Mar 28, 2022 at 2:52 PM Avi Kessner <
akessner@...> wrote:
?
Copy/paste inline, or actually inline?
What's the difference?
--
J. B. (Joe) Rainsberger :: ?:: ::
?
It's in the tests, because you start with inlining the code tested in the failing test.?
IIUC everything happens in the tests, until you get to the point where you uncover that "missing test" JB is speaking of.?
--?
Arnaud Bailly - @dr_c0d3
On Mon, Mar 28, 2022 at 7:07 PM Avi Kessner <
akessner@...> wrote:
Very nice, but one piece confuses me. Am I supposed to delete if statements in the production code, or if statements in the tests? Also, can this help with bugs related to third party libraries?
On Mon, 28 Mar 2022, 16:27 J. B. Rainsberger, <
me@...> wrote:
On Sat, Mar 26, 2022 at 4:32 AM Jacqueline Lee <
jmasonlee@...> wrote:
Hey J.B.?
Do you have this description of a Saff squeeze posted anywhere? I have a blog post that I'm writing that references a Saff squeeze, and I'd love to just link to a description rather than writing it up, but I can't find a good description elsewhere. Thanks!
I simply haven't published it yet. And that's funny, because I've been doing it _often_ the past few days.
I finally published something about it. Let's see how the world reacts:
Thank you for prompting me finally to write it. :)
--
J. B. (Joe) Rainsberger :: ?:: ::
?
On Fri, Mar 11, 2022 at 12:55 PM J. B. Rainsberger <
me@...> wrote:
One reasonable way to get from a few slow-running end-to-end tests to some strategic unit testing is to do the following whenever you encounter a bug:
[...]
Another suggestion: apply the Saff Squeeze. Think "debugging with automated tests".
Start with a failing test.
1. Inline the action of the test: that's the central function that you invoke to make the test _do_ something.
2. Make invisible things visible (private -> public in many languages).
3. Prune away dead code, such as the branches of an `if` statement that this test's input won't run. Maybe unroll a loop.
4. Add assertions to check intermediate results, especially the conditions of `if` statements or the stopping conditions of loops. Do this until you add an assertion that fails.
5. After you add a new failing assertion, delete the rest of the test; it won't execute, anyway.
Now you have a smaller test that fails for the same reason as the original test. Commit. Maybe now it's obvious what caused the defect. Yes? Fix it. No? Repeat the process.
This is one way to uncover smaller unit tests that would have helped you. Over time, you'll get to know which kinds of smaller unit tests you want to practise writing.
--
J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
J. B. Rainsberger