TDD

The Noobification Of Everything

Friend Matt asked me to elaborate on "the noobification of everything" in the geek trades. This is a floppy vague one as yet, so be prepared to play fast and loose. The so-far endless demand for new software has created a poor skills distribution curve into the trade. Divide ever-so-arbitrarily our ranks into 5, dreyfus-style or thereabouts. 1’s know where to put semi-colons. 5’s know as much as we all know about geekery. We have way too many 1’s for …

The Noobification Of Everything See Full Post

Strange Borders (And Bitching)

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. Bitching about clients brings a mixed lot of positive benefit and negative ill. Co-bitching is bonding, for instance. A way for us share, a kind …

Strange Borders (And Bitching) See Full Post

How’m’I Gonna Test This?

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 a test at all? What is the test doing for me? This touches a mantra you’ll hear me mutter over and over. "i don’t work …

How’m’I Gonna Test This? See Full Post

Hard-TDD vs Soft-TDD

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 skip that. Hard vs soft here isn’t about technique, it’s about what we believe the value of the technique includes. And don’t be confused, there …

Hard-TDD vs Soft-TDD See Full Post

Five Underplayed Premises of TDD

This entry is part of 9 in the series Underplayed Premises

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 …

Five Underplayed Premises of TDD See Full Post

Crabby Note To TDD Journeyfolk

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 …

Crabby Note To TDD Journeyfolk See Full Post

Automocking: Don’t Take Hard Shots

This entry is part of 2 in the series Automocking

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 …

Automocking: Don’t Take Hard Shots See Full Post

Automocking: Behavior Tests Are Not Quite

This entry is part of 2 in the series Automocking

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, …

Automocking: Behavior Tests Are Not Quite See Full Post

We’re In This For The Money

(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 …

We’re In This For The Money See Full Post

Scroll to Top