A friend asks what to do about a bad pair. That’s a juicy one, and prods me to muse. Why do we pair? It’s one of the techniques we adopt to increase productivity. That’s measured in geekery by insights per hour, or such like. Maybe if we understand what makes good pairing, we can get closer to some possible remedies for bad pairing? Good pairing involves a bunch of otherwise disconnected-seeming aspects. These form an interactive context in which the …
UPDATE: This post has been restructured and made into a video, you can view it here. Here are five underplayed premises of TDD. Why "underplayed"? Well, they’re there. Hardcore TDD’ers model them all the time. But it feels like they just don’t get the camera time. I want TDD coaches and teachers to step back from "what’s an assert" and rigid rule systems, and highlight these premises in their own work. The money premise: we are in this for the …
TDD journeyfolk, let me rattle your cage a little this fine afternoon. Lemme sketch a common situation for me. I have a problem, not a small one, to be solved in a tech stack I’m not intimately familiar with. Further, some aspects of the problem are things no one on stack overflow has ever done before. They look, on paper, like they might be doable, but there’s no drop-in and very little advice. I’m in this situation where I have …
Yesterday, I started my explanation about not using automockers. But that muse is about just one aspect of the automocking world: interaction tests. And automockers can do a lot more than that. We could use an automocker for years without ever writing an interaction test. So, then, again, why don’t I? I’m an old fart, ya know. To the extent I’ve learned anything at all in my time here, I’ve learned that every strength is a weakness. I see that …
So, with the intent firmly in our minds, from yesterday, I feel closer to explaining my automock resistance. There is still some teasing apart to do. Automocking tools bring several possible aspects to the floor. The first of these is by no means required by automockers, but is commonplace. And that is behavior-based testing. Behavior-based testing is the kind of testing where i validate A in an A->B relationship, by asserting that B’s methods were called. If, in setting X, …
(When I’m teaching and coaching, I have a number of premises that I discuss and that will show up somewhere in everything I do. Here’s the money premise, which I usually bring up at the earliest opportunity.) Look, kids, we’re in this for the money. Somehow you got the idea that TDD, pairing, micro-stepping, and refactoring are not about increasing your productivity. It could be the misguided craftsmanship movement, who give you the excuse to say "we don’t have time …
