I like the idea but I'm afraid that this stack of stashes can result in some merge work when doing refactors in one step. I prefer have all the code in my branch the whole time and just stub implementations and set unfinished tests to disabled.
In TDD, at least as I learned it, you're supposed to write a test, write enough code to get it to pass, then write the next test, and so on. That doesn't require stashes between steps. The only reason the stashes are 'necessary' here is because the author is adding all their tests up front.
Not exactly. The author’s example is a bit cutesy, which makes it a bit difficult to tell what’s going on.
What’s happening here is the author is doing outside-in development, but doesn’t want to use mocks or spies to test dependencies that don’t exist. So, when they discover the need for a dependency—which might not be immediately obvious—they stash their work so they’re not bothered by a failing test and half-done code while they implement the dependency.
It’s a technique I use pretty often myself, though not quite as heavily nested as here, and only when I’m genuinely surprised by the need to implement something else before I can make my current test pass.
globalmatador|1 year ago
onion2k|1 year ago
jdlshore|1 year ago
What’s happening here is the author is doing outside-in development, but doesn’t want to use mocks or spies to test dependencies that don’t exist. So, when they discover the need for a dependency—which might not be immediately obvious—they stash their work so they’re not bothered by a failing test and half-done code while they implement the dependency.
It’s a technique I use pretty often myself, though not quite as heavily nested as here, and only when I’m genuinely surprised by the need to implement something else before I can make my current test pass.
ksoajl|1 year ago
[deleted]
kkjkj|1 year ago
[deleted]