TDD

TDD Tests Are First-Class Code

My standards for TDD microtests are the same standards I have for shipping code, and I follow them in microtests for the same reason I follow them in shipping code: they make me faster. This geekery muse is comfort food, for me and maybe for you, but I want to keep stressing: I fully endorse and support my sibs out there on the street protesting this violent police uprising. Stay safe, stay strong, stay kind, stay angry. Black lives matter. …

TDD Tests Are First-Class Code Go to Post »

Microtest TDD is Gray-Box

Microtest TDD is a gray-box testing approach, neither entirely inside nor outside the code it tests. Let’s talk that over. Before we dive in: Black lives matter. Stay safe, stay strong, stay kind, stay angry. Let’s not just embrace change, let’s initiate it. Any step you take helps, provided only that it’s doable, it’s not definitely backwards, and it’s not the last step. In the ’70’s, an important movement developed in testing theory, called "black box" testing. The idea is …

Microtest TDD is Gray-Box Go to Post »

Turning Implicit into Explicit

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 Go to Post »

Model-View, The Desktop, and TDD

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 Go to Post »

Microtest TDD: Economics

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 Go to Post »

Microtest TDD: More Definition

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 Go to Post »

Microtest TDD: The Big Picture

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 Go to Post »

Refactoring Strategy: Move It Where You Can Test It

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 Go to Post »

Refactoring: Invert Dependency With Observer

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 Go to Post »

Refactoring: Demeter-Wrapping

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 Go to Post »

Scroll to Top