On Tue, Mar 29, 2022 at 5:31 PM Russell Gold <
russ@...> wrote:
On Mar 29, 2022, at 2:58 PM, J. B. Rainsberger <
me@...> wrote:
On Tue, Mar 29, 2022 at 1:57 PM Russell Gold <
russ@...> wrote:
I¡¯ve never heard of the ¡°Mikado method,¡± but that¡¯s pretty much the way I learned to do TDD.
Saff¡¯s technique seems interesting, and I will keep it in mind for the future; I¡¯m not sure yet exactly where it would help. Most of the problems I deal with are errors that wind up being caught in integration testing, because we missed a unit test. There, the problem is that it is not immediately obvious what test is missing, because we haven¡¯t even reproduced the problem other than the integration test: and it doesn¡¯t directly call the production code, so we cannot inline anything useful.
That's _exactly_ what the Saff Squeeze does: it starts with a failing, bigger unit test and produces a missing, smaller unit test. It merely uncovers that test systematically instead of relying on your intuition to imagine it.
But I don¡¯t have a failing unit test. I have a failing
integration test (and one that typically takes close to an hour to run through all setup and initialization each time).?
I infer that you're using the term "integration test" to mean "unit test for a bigger unit". It's still a unit, even if it's a large one. :) (Yes, I'm trying to rehabilitate the original meaning of "unit": any independently-inspectable part of the system. And yes, that means that the entire system is a unit.)
If you're starting with a failing test that takes 1 hour to run, then the Saff Squeeze remains perfectly effective, but perhaps you can't afford the time to do it that way. Or you merely might not have the patience for it. I wouldn't blame you. In that case, you might need to guess at some smaller failing unit tests, then Squeeze from there.
Even so, I propose two possibilities:
1. I can imagine situations in which Saff Squeeze would lead you to discovering the cause of the defect sooner than groping in the dark, hoping to find the failing part of the code, even if the first few iterations of the Squeeze took an entire day.
2. The Saff Squeeze might be helpful, even if you can't afford to _run_ the tests for the first few iterations. Perhaps even systematically inlining would work better (and feel better) than using a debugger or other, less-systematic techniques.
?
When I get a failing unit test, I generally just revert the change that caused it and try again. If that¡¯s not practical for some reason, I will try this.
You're assuming that you know the change that caused it. The whole point of this technique is to help find the cause of a defect when we don't know the cause of the defect by other means.
--
J. B. (Joe) Rainsberger :: ?:: ::
