Agile Otter Blog

using(Playback) {    sut.PerformAction(parameter); } This is the last part of a common style of mock test. We see the system-under-test (sut) being asked to perform some action, and some parameter is passed to it.  We know it's a mock test because of the Playback bit.  What is being tested here? Well something about PerformAction is being tested. Not much there. No clear assert written at the bottom of the test to capture our attention. Let me narrate as I work through the actual code before me, and maybe the readers can respond to tell me whether this really is mocking done badly, or I'm "just not used to good mocking." I struggle not to look at the test name, so the code can speak to me more directly. The parameter is not interesting, it is just a string.  There is another variable, which is a stub, but it's not used inside playback. There is a 'record' section, set aside with 'using' and not (thankfully) a #region. In the record sectio...

On the television as I type this is a show called "Amazing Wedding Cakes", which is unsurprisingly about cake making. In the current episode a bride has ordered 190 individual single-serving cakes. The team is struggling with a trade-off between doing the work on time and doing the work really well. We all do that. Software is so very much the same. We simply don't have time to obsess on every detail, but we also can't skimp on essential details. We need to make both radial and linear improvement, but we can't abandon our charter to deliver quality. This has been a running meme this week, whether one can afford quality and whether skimping quality will help a team go faster.  I've gone on record enough times saying that I don' think you go faster writing poor code, and I echo Uncle Bob Martin in saying that our most significant impediment is the bad code we have to work in. In the end, the boss was pretty angry about the care that was taken with each...