On Mon, Mar 28, 2022 at 2: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?
You're deleting code from the test as you inline parts of the test. You're only changing production code in order to make the test work (making non-public parts public, mostly).
--
J. B. (Joe) Rainsberger :: ?:: ::
?
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