TDD

TDD on the Front End

TDD, Programming / / 9 minutes of reading

A recurring respondents’ theme is “TDD is irrelevant in front-end code”. It’s easy to offer/receive this comment combatively, but I think a little more rich discussion of the factors involved might bring us to new and different positions about UI and TDD. Most folks who offer that are living in some sort of JS world: their code is client-side scripts attached to html pages to render various contents received from another application. Their browsers are in effect frameworks, inside of […]

TDD on the Front End See Full Post

Readability And Scannability

TDD, Programming, Change Harvesting / / 6 minutes of reading

I distinguish quite strongly between “readability” and what I call “scannability”. I think that our trade’s pedagogues, even our very good ones, conflate the two, and in so doing inaccurately describe programming and ineffectively prescribe remedies. Maybe the way to approach the idea is through your experience of seeing. Humans — most vertebrates, in fact — rely heavily on "seeing". The fabric of our experience is richly visual. A large portion of our neocortex is given over to it. Its

Readability And Scannability See Full Post

Kontentment And Human Arcs

TDD, Programming, Kontentment / / 7 minutes of reading

Aight. I been away from programming for a couple of months, but there was a reason I started talking the other day about the kontentment project: I’m wanting mucho change in it. For a talk I’m giving, I want the ability to draw human arcs, with the same ease with which I can draw human lines. So I set out today to get that in. Human straight lines start with a line segment AB. Pick two random locations on that

Kontentment And Human Arcs See Full Post

The Cost of Changing Microtests

TDD, Programming, Change Harvesting, How I Work / / 7 minutes of reading

The “How I Work (Test-Driving Mix)” drew some questions and comment. How I Work (Test-Driving Mix) Here’s one: a respondent says, “If I write a lot of small tests and I change how a feature works, I have to change or throw out all those microtests, which is a lot of work.” (The respondent proposed an answer for this problem, and it’s not a bad one, but raises some other questions we might get to later.) The one-liner response: “For

The Cost of Changing Microtests See Full Post

How I Work – Preaching And Practicing

TDD, Geekery, Refactoring / / 6 minutes of reading
This entry is part [part not set] of 1 in the series How I Work

A respondent asks, "Are you always able to practice what you preach? I don’t mean intentionally dropping but unintentionally as your mind is sloppy. I have great difficulties in applying 100% of my "knowledge" 100% of the time." Sometimes questions open up huge areas with lots of issues and subtexts and angles, and this is one. It’s too big to fit in one or two tweets. First, the direct answer: Oh, hell no. I am definitely not always able to

How I Work – Preaching And Practicing See Full Post

TDD Pro-Tip: Suspect Sentinel Returns

Pro-Tip, TDD, Kotlin, TSD / / 4 minutes of reading

TDD Pro-Tip: I suspect sentinel returns, and though I still use them, it’s generally because I haven’t found the right formulation yet. I’m working on the TSD project today, and I’ve got a nasty little chunk of code I wish weren’t nasty. (It’s in this file, and of course, you’re welcome to grab the whole repo, which will enable you to really make fun of me.) You don’t have to look at the code, I’m not going into it, but

TDD Pro-Tip: Suspect Sentinel Returns See Full Post

TDD Pro-Tip: Make The Tacit Explicit

Change, Coaching, Pro-Tip, TDD / / 5 minutes of reading

Refactoring Pro-Tip: When I make tacit relationships explicit I nearly always improve my code. Once I move past syntactical refactorings into semantics, this is often my first set of moves. So what does this mean, "tacit" vs "explicit", in code? Maybe the easiest way to come at it is with a very dumb example. The simplest tacit relationship I can think of is modeling a one-to-one relationship using two lists. The first list is composed of tokens. The second list

TDD Pro-Tip: Make The Tacit Explicit See Full Post

When To Start Doing TDD

TDD, Change, Coaching, Pro-Tip / / 6 minutes of reading

TDD Pro-Tip: TDD-blockers are everywhere for me, even now, after twenty years of practicing it, so I still try new ways to work around them, and I don’t always find them, and I wait for next time. A respondent had a great question, and this is a kind of "sideways" answer. The question: Given that we’re halfway through an app w/o an architecture that TDD’s well, should we start TDD now or wait for the next greenfield chance to do

When To Start Doing TDD See Full Post

One Story, One Day

Change, Coaching, TDD / / 3 minutes of reading

TDD Pro-Tip: The step-wise technique has to account for what the user experiences when, so I have to build ways to control that when stories get bigger than a day. (A new friend asked the question: when stories get hefty, how do we "live at HEAD" without exposing our users to code that’s still WIP.) First the one-liner: don’t do that. Don’t work on stories that are bigger than a day. What I mean is, there’s a cost to controlling

One Story, One Day See Full Post

Large Stories Mean Side-By-Side Technique

Coaching, Pro-Tip, TDD, Change / / 6 minutes of reading

When I have to have WIP that’s live in production, I pretty much have to use all the approaches for side-by-side development. In some recent muses, we’ve talked about "in situ" vs "side-by-side" approaches to changing code. First, let’s refresh our concepts for these two phrases. In both cases, we have a bunch of code A, and we wish we had a bunch of code B. B might incorporate all of A, or it might be more like A’, or

Large Stories Mean Side-By-Side Technique See Full Post

Scroll to Top