Five Underplayed Premises of TDD

This entry is part [part not set] 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 [part not set] 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 [part not set] 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

Stop Using Logs Everyday

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 developers use the log all day long during development. Everyone from time to time does "print" debugging, of course. No technique on earth can entirely …

Stop Using Logs Everyday See Full Post

Defining Agile: A Musing

Defining Agile Sooooo, I saw a couple folks arguing earlier about what is or isn’t Agile. That’s okay. People do that. Analytical people thrive on doing that. Anyone who’s gotten to the level of journeyfolk in any arena will seek to define that arena. All very healthy stuff. Nowadays I tend to avoid these arguments. I have my reasons. First, there is no definition anywhere on earth of anything that can’t be abused or misused willfully or not. There is …

Defining Agile: A Musing See Full Post

User Stories Are Playing Pieces: The “Right Writing” Is Wrong

User Stories If you are concerned about how you write a user story, you have missed the entire point. A user story is a little card that reminds us of all the actual conversations we’re currently actually having. If the words "bathtub farting" are enough for the team to actually converse about what they signify, they’re enough for what they’re for. The very first step you take that’s away from "user story is a marker" is the road back to …

User Stories Are Playing Pieces: The “Right Writing” Is Wrong See Full Post

Me & Molly & Marvelling

I’ve been having a lot of trouble getting to sleep lately. I go to bed cuz it feels like it’s time. Sometimes my body won’t settle, itching and twitching and such like. Sometimes my mind won’t. Usually it’s a mixture of both. So I get back up. But then I’m tired as hell, and it seems like I’m sleepy again, so I go back. Rinse, lather, repeat 3-5 times. Eventually one of two things happen. Either I finally manage to …

Me & Molly & Marvelling See Full Post

The Driven Premise

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 only if you lined them up that way. The driven premise says that tests & testability are first-class participants in design. When they are, then …

The Driven Premise See Full Post