Steven Harman

Maker and Breaker of Things

Toward a Better Use of Context/Specification

If you’ve hand-rolled your own Context/Specification apparatus to support your test spec-first lifestyle, you’ve likely got a base class that looks something like the following:

The above is co-opting an existing unit testing tool into something more language-oriented and behavior focused. In this case we’ve built upon MbUnit, adding a couple of hook methods that are responsible for

  1. setting up the context before an individual specification - context
  2. optionally doing any necessary teardown after each specification – decontext

An example

Using this base class, we’ll end up with specs that might looks something like

Here we’ve set up a common context that holds true for each of specifications that follow it. This is also a common pattern used in classic unit testing and in fixture-per-class style Test-driven Development. In fact, the only real between the above and what I’d have done in fixture-per-class style TDD is the_use_of_underscores, intention revealing names, and the context hook method.

Is that really any different?

These modest cosmetics are not what differentiate Context/Specification from other styles of test-first development. For me, the real difference is the realization that there are often many contexts under which a particular behavior my be exercised, each producing an observable and possibly different set of results.

With Context/Specification we’ll often have many fixtures per class/feature/functional area of the code base. Doing this allows us to keep the context as simple as possible and focused on the behavior being specified. I’ve found that I tend to have a single file-per-class/functional area, with any number of contexts (fixtures) in each file.

Another big distinction is that specifications should be side effect free. A specification is an observation about the interactions that occurred or the state of the system after some behavior has been exercised.

Make it explicit!

We want small, focused contexts, yes? And we want side effect free specifications too, yes? So why not leverage our tools to help guide us in that direction? YES!

Consider the following tweak to the concerns base class

Such a base class will only set up each context once, no matter how many specifications are made against the context. This does a couple of things for us

  • requires side effect free specifications
  • guides us toward smaller, more focused contexts
  • might actually make our specs run faster!

As for the running faster bit, that is not guaranteed as it really depends on how you were writing your specs before making this change.

Some things to watch for

If, however, you were following more of a fixture-per-class style, you might find a drastic reduction in how long it takes your spec suite to run. The corollary is, of course, that you likely don’t have small contexts. That is trouble and is often an indicator that the one, large context is itching to be split out into two or more discrete contexts.

Upon switching your base class over to this more rigid Context/Specification pattern, you might also find that you have some – or many – broken specs. This is an indicator that those broken specs were not side effect free. Well, actually its suggesting that some of the sibling specs weren’t side effect free and they are now causing other specs to break.

Notes:

The portions of this article relating to changing from a standard context set up to a once-per-fixture style apply to most of the hand-rolled Context/Specification base classes I’ve seen in the wild.

If, however, you are using a tool like MSpec, then you’re in good shape as Aaron applied this same philosophy out of the gate. And if you’re not using MSpec, I’d encourage you to take a look at it for inspiration, if nothing else.

A Sketch of Our Ideation Pipeline

"Initial sketch of our Ideation Pipeline"

This is an initial sketch of an Ideation Pipeline my team will be using to help drive the direction of a product we’re working on. The sketch is based on a discussion we had about how we currently get from an idea to delivering on that idea, and how we’d like to do that going forward.

While we probably should have done a full on Value Stream Map, we didn’t. And the only excuse I have is that we’re kicking this product off so there isn’t really a set way we do things… not yet anyhow.

At any rate, later today I’ll be turning this loose sketch into a physical Kanban board that we’ll used to track and pull ideas through our ideation process, and feed the resulting features into our development process.

But first, I want to explain how the whole thing will work, or at least how we’re going to start – I’m sure we’ll tweak some things, and change out whole parts of this process as we go along. Let’s get started.

How-To: Ctrl + Alt + Del in Remote Desktop

I’m a fan of Microsoft’s Remote Desktop; it’s built into Windows and allows me to quickly and easily administer a remote box from the comfort of my own work station. I use it at my house to administer the headless servers on my home network, the Subtext build server, and the co-located VelocIT servers.

Gotta’ love that magic!

"Ctrl + Alt + Del in Virtual PC"

Today a co-worker asked me how to send the infamous Control + Alt + Delete keystroke combination to a machine he was working on via RDP. This is a pretty common keystroke to use when trying administer windows… it does have uses other than just killing the box.

With Virtual PC there is menu item to send the keystrokes on to the virtual box. Go to the Action menu and select the Ctrl + Alt + Del option.

And with Remote Desktop?

"The only keyboard you'll ever need"

Well it’s not quite as obvious. Actually it’s not an obvious solution at all… hell it might not even be documented!

For the record, since I already knew the answer I decided to be lazy and didn’t bother to search the tubes for any official documentation.

To send the Ctrl + Alt + Del keystroke combination via RDP you actually need to use…

Ctrl + Alt + End

WTF? That sure is intuitive!