TDD

Turning Implicit into Explicit

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

Turning implicit understanding into explicit code is a great productivity & quality step. Let’s talk about some whys and hows for that idea. As we forge into the topic, please do remember, this is just comfort food, not the main story. I proudly support my friends & family who are working for change in the world, and encourage them to keep at it. Stay safe. Stay strong. Stay kind. Stay angry. Black lives matter. An implicit understanding is anything a […]

Turning Implicit into Explicit See Full Post

Model-View, The Desktop, and TDD

TDD, Change Harvesting, How I Work / / 8 minutes of reading

Today, a basic topic: Model/View, the Desktop and TDD. Some geeky respite, and enjoy. We got a lotta work waiting for us after this break. Stay safe. Stay strong. Stay kind. Stay angry. Black lives matter. Demand different. The basic idea behind all Model/View schemes, and there are several of them, is just this: draw a thick line between what your program does and how your program shows what it does. In other words, it’s a compositional heuristic, guidance for

Model-View, The Desktop, and TDD See Full Post

Microtest TDD: Economics

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

The economic aspects of microtest TDD are inextricably tied to the operational aspects of it. If we concentrate only on the artifacts involved, we will lose the picture and misunderstand the value proposition. As a professional geek, the heart of my job is changing rigidly structured imperative text in collaboration with other humans, in order to meet a variety of locally or temporally aligned goals. That’s fancy talk for "I change code, in community, for money." The central event is

Microtest TDD: Economics See Full Post

Microtest TDD: More Definition

TDD, Programming, How I Work / / 5 minutes of reading

What’s a microtest, anyway? I write a ton of tests as I’m building code, and the majority of these are a particular kind or style of test, the microtest kind. Let’s talk about what I mean by that, today, then we’ll talk later about how that turns out to help me so much. A microtest is a small, fast, precise, easy-to-invoke/read/write/debug chunk of code that exercises a single particular path through another chunk of code containing the branching logic from

Microtest TDD: More Definition See Full Post

Microtest TDD: The Big Picture

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

I think of my style of coding as "microtest TDD". That can be misleading for folks, so let’s take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I’m in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them,

Microtest TDD: The Big Picture See Full Post

Refactoring Strategy: Move It Where You Can Test It

TDD, Programming, Refactoring / / 6 minutes of reading

When I can’t test it where it is, I look to move it somewhere else, where I can test it. Today’s notion isn’t so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it’s an endpoint. This is how Java+Swing works, or Python+Flask. When

Refactoring Strategy: Move It Where You Can Test It See Full Post

Refactoring: Invert Dependency With Observer

TDD, Programming, Refactoring / / 8 minutes of reading

Another refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unraveling it all can be tricky. (Note: We aren’t remotely done talking about first and second-order refactorings, there are plenty more to go. But I’m not writing a catalog, I’m working a project, so when a hefty one like this comes along, that’s when I’m talking about it. You’re gettin’ em

Refactoring: Invert Dependency With Observer See Full Post

Refactoring: Demeter-Wrapping

Refactoring, TDD, Programming / / 5 minutes of reading

Today, another small 2nd-order refactoring. I call it "wrap a Demeter". As with the others, this is a very modest step, but still quite useful in some situations. Demeter violations are places where a client accesses not just an upstream service, but that service’s upstream services, or even that service’s service’s upstream services. It’s a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething() a is getting a B, but

Refactoring: Demeter-Wrapping See Full Post

Large-Scale Refactorings

TDD, Programming, Refactoring, Change Harvesting / / 7 minutes of reading

Large-Scale Refactorings — given the recent refactoring-related muses, a respondent asked me to talk about large or larger scale refactoring work. (I love it when people’s questions trigger my writing. Please do ask these things.) First things first, “large scale refactoring” is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn’t mean “changing my design”, it means “changing my design

Large-Scale Refactorings See Full Post

Second-Order Refactoring: Narrow The Question

Programming, Refactoring, Change Harvesting, TDD / / 4 minutes of reading

Another small second-order refactoring for you today. I call it “narrow the question”. If you’re asking an object for data, ask for exactly what you want to know, instead of what you’d need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the

Second-Order Refactoring: Narrow The Question See Full Post

Scroll to Top