Thinking this morning about strange borders, led there by a typically weird geepaw route. If u didn’t know, coaches sit around all the time and bitch about their clients. This is perfectly ordinary and maps onto all jobs I think. Such behavior is "good thing, but". It’s important to do and it’s risky as hell. […]
Strange Borders (And Bitching) Read More »
Today’s muse, another damned geepawism: RORA technique. RORA means "Runs Once, Run Away". It is the standard technique in a great many software dev environments. A developer is tasked with some story. She codes it using a variety of half-assed techniques, including mostly GAK testing. More geepawism: GAK means "geek at keyboard" testing. You know
RORA – Runs Once, Run Away Read More »
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 »
