This year, like last, I completed the Advent of Code
puzzles. I’m always surprised when I jump into these puzzles by how much my normal approach to writing code fails, but the ideas behind it still succeed.
My approach to development is heavily based on the ideas in GOOS
. I do an outer and inner TDD loop, using unit test feedback to tease out a reasonable design and acceptance test feedback to ensure that I don’t break anything along the way (and am making progress.) While there’s a lot more to it than that, you assume I’m bought into the “mockist” style of TDD.
If you watched any of my streams or watch (almost) any of the videos on YouTube, you’ll see I almost always start with an acceptance test. My approach doesn’t differ there. I take the example they given when laying out the problem and assert that my solution computes it correctly.
From there, my approach differs from my usual one. I don’t use any mock objects. I only write tests when I’m carving out non-trivial bits of logic and it’s convenient.
I’d argue that this is totally consistent with the ideas behind the TDD technique in GOOS. I don’t need unit-level feedback. I’m not trying to produce a system with good design, so I don’t care about my units being easy to test. I’m not trying to discover a good design for the system, either. Once the acceptance test passes, I’m hopefully done.
It’s all about feedback. Simple acceptance tests are all the feedback I (usually) need for these puzzles.