I often say "how am I gonna test this?" but — language being what it is — my meaning in asking that is not likely graspable by a noob. To get at what i’m really wondering when I ask this, I may have to take a few asides & detours. First. Why am I writing […]
How’m’I Gonna Test This? Read More »
Alrighty-then. This Hard-tdd vs Soft-tdd thing. A couple of days ago, I worked through some underplayed premises of TDD here. Along the way, I touched on what I call Hard TDD vs Soft TDD. The terms derive from AI, where proponents differ on soft-AI vs hard-AI. A semantic association, not a real analogy, so i’ll
Hard-TDD vs Soft-TDD Read More »
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
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
Five Underplayed Premises of TDD Read More »
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
Crabby Note To TDD Journeyfolk Read More »
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,
Automocking: Don’t Take Hard Shots Read More »
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
Automocking: Behavior Tests Are Not Quite Read More »
(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
We’re In This For The Money Read More »
I don’t "believe" in logs, generally. What I mean is, for developers, logs should be seen strictly as a story for ops, not a development tool. I understand why ops needs to see logs. Ops is a customer just like any other, and what they need, we can supply. But I see far too many
Stop Using Logs Everyday Read More »
EDIT: This premise has been renamed the "Steering Premise", you can see the full video breakdown here. The Driven Premise Here’s an illustration of the most basic principle of TDD, what I call the "Driven Premise": there once was a queen who had a thousand consorts, each more brave and handsome than the next. But
The Driven Premise Read More »
