Exploration Through Example

I’ve been growing a little disillusioned with my graphical workflow tests: implementing the test support code seems like a lot of work for little benefit. (It has nothing to do with the graphics—I’d have to write the same methods in a FitLibrary DoFixture or if I wrote the workflows directly in Ruby.)

So it was with a heavy sigh that I began to create this test:
(more…)

I’ve printed a new poster, shown below. Free for the asking. It’s 12×18 inches (30×45 cm). I’ll be bringing about 50 of them to SDTConf, so don’t ask if you’ll be there.

At James Bach’s request: testing needs incisive and restless thinkers.

UPDATE: As requested in the comments, I’ve expanded on this.

I wrote a paper for PNSQC 2005 that I seem to never have put on line. Here’s the abstract:

This paper argues that the continuing problems we have with requirements elicitation and transmission are not a result of poor skills or sloppy people. It’s rather that the entire idea is based on dubious assumptions. A different assumption is introduced, namely that effectiveness can only be obtained by parties having iterative conversations over time, and that communication is meant more to provoke right action than to transmit understanding. Based on examples of this assumption in practice, suggestions for software development are sketched.

“The Gap Between Business and Code” (PDF)

Unless the contract contains unexpected surprises, I’ll be writing a book on scripting your Mac with Ruby for the Pragmatic Bookshelf. Like Everyday Scripting, it will teach by way of projects. I’m looking for reviewers and ideas. The ideas could be projects to do or technologies to cover (e.g., Growl).

By way of example, here are my notes about the first project.


Pretend you're someone who needs to be reminded to take breaks
from the computer. This program provides them.

Another project I want to do is write a plugin to Mail that will let me kill threads in ruby-talk as a way of controlling the flood.

This sounds like a neat event. I’ve put it on my calendar. (UPDATE: I’m now one of the organizers.)

Do you wish you could attend the Agile conferences and XP days, but can’t get the funding or the travel budget or the time off work? Well there is one agile event that you can even attend from your own bath — the Naked Agilists!

Last year’s event was so successful that we’re running another. And you only need Skype to be able to attend. Save the date now:

Date: Saturday 19-Jan-08
Time: 20:00 GMT - 21:30 GMT
Venue: Your place, or mine

The event format is a Skype conference, supported by chat, and a website hosting slides and stuff. There’s also a mailing list where you can find more details of what happened last time, and loads of feedback on the event itself.

The event will be chaired by Leigh Mullin, who did such a great job last time — particularly to keep out the inevitable “tourists” who were hoping the “naked agilists” all had webcams! Please join the mailing list and propose a session. This time around we’re hoping to run with two different kinds of session:

• Experience Reports, lasting 2, 5 or 10 minutes. Think of these as mini blog posts — your chance to share a quick idea or observation with the rest of us. Last time, most presenters prepared a few slides to support their session, and most were also followed by a few minutes of Q&A, discussion and Skype chat.

• Open Questions. You’ll get 1 minute to ask the group a question, and then there will be 10 minutes of discussion. This is your chance to tap into the experience and expertise of the assembled agile experts.

If you would like to present or table a question, please join the mailing list and post your suggestion there. We’ll put the programme together early in the New Year, so please get your entries in early. Detailed intructions for participating in the call itself will only be posted on the mailing list, so even if you simply want to be in the “audience”, join the list now to avoid disappointment.

In product code, not repeating yourself is almost always a good idea. In tests, it’s not so clear-cut. Repeating yourself has the same maintenance dangers as it does for code, but not repeating yourself has two additional downsides:

• A common knock against well-factored object-oriented code is that no object does anything; they all just forward work on to other objects. That structure turns out to be useful once you’re immersed in the system, but it does make systems harder to learn.

  One purpose of tests is to explain the code to the novice. Remove duplication too aggressively, and the tests do a poor job of that.

• Another purpose of tests is to make yourself think. One way to do that is to force yourself to enumerate possibilities and ask “What should happen in this case?” That’s one of the reasons that I, when acting as a tester, will turn a state diagram into a state table. A state diagram doesn’t make it easy to see whether you’ve considered the effect of each possible event in each possible state; a state table does. (It’s not as simple as that, though: it’s hard to stay focused as you work through a lot of identical cases looking for the one that’s really different. It’s like the old joke that ends “1 is a prime, 3 is a prime, 5 is a prime, 7 is a prime, 9 is a prime…”)

  If you factor three distinct assertions into a single master assertion, it’s easy to overlook that the second shouldn’t apply in some particular case. When you factor three distinct setup steps into one method, you can more easily fail to ask what should happen when the second setup step is left out.

So as I balance the different forces, I find myself writing test code like this:

  # Guard against manufactured URLs.
  def test_cannot_update_a_user_unless_logged_in
    new_profile = NewProfile.for(’quentin‘).is_entirely_different_than(users(:quentin))

    put :update,
        {:id => users(:quentin).login, :user => new_profile.contents}
        # Nothing in session
    assert_redirected_to(home_path)
    assert_hackery_notice_delivered
    new_profile.assert_not_installed
  end

  def test_cannot_update_a_user_other_than_self
    new_profile = NewProfile.for(’quentin‘).is_entirely_different_than(users(:quentin))

    put :update,
        {:id => users(:quentin).login, :user => new_profile.contents},
        {:user => users(:aaron).id}
    assert_redirected_to(home_path)
    assert_hackery_notice_delivered
    new_profile.assert_not_installed
  end

There’s duplication there. In an earlier version, I’d in fact reflexively factored it out, but then decided to put it back. I think the tests are better for that, and I’m willing to take the maintenance hit.

Nevertheless, there’s a problem. It’s not obvious enough what’s different about the two tests. What to do about that?

Consider explaining the evolution of a program over time in a book. Authors don’t usually show a minimal difference between before and after versions. Instead, they show both versions with a fair amount of context, somehow highlighting the differences. (When I write, I tend to bold changed words.) I wish I could highlight what’s special about each test in my IDE, so that it would look like this:

  # Guard against manufactured URLs.
  def test_cannot_update_a_user_unless_logged_in
    new_profile = NewProfile.for(’quentin‘).is_entirely_different_than(users(:quentin))

    put :update,
        {:id => users(:quentin).login, :user => new_profile.contents}
        # Nothing in session
    assert_redirected_to(home_path)
    assert_hackery_notice_delivered
    new_profile.assert_not_installed
  end

  def test_cannot_update_a_user_other_than_self
    new_profile = NewProfile.for(’quentin‘).is_entirely_different_than(users(:quentin))

    put :update,
        {:id => users(:quentin).login, :user => new_profile.contents},
        {:user => users(:aaron).id}
    assert_redirected_to(home_path)
    assert_hackery_notice_delivered
    new_profile.assert_not_installed
  end

Something for IDE writers to implement.

A couple years ago, Agile “crossed the chasm” (Geoffrey Moore’s term). For a while, I’ve been meaning to write a blog post questioning whether that high tech adoption model is working for Agile. Fortunately, I don’t have to. I gave a lightning talk on the topic at the Functional Testing Tools workshop, and a video of that talk has been posted.

Other lightning talk videos from the workshop are available. (Warning: my “boundary objects” talk is incoherent in a crucial place because I used the wrong word twice and then changed the subject too quickly.)

Adam Geras and I will be “producers” for this “stage” at Agile2008. Here are some notes.

I’m imagining a single room for the duration of the conference. We won’t have a huge number of sessions. (Problem: This stage has a specialized topic and few sessions. It is not the Testing Stage, though it’s a natural home for many types of testing sessions. Where do all the other worthy testing submissions go?)

Only the first half of the stage will have prescheduled sessions. The second half will be devoted to “repeat and request”.

Repeat: Since there will be many simultaneous events at the conference, some people will hear about a great Example session after it’s too late to go. Within our room, we’ll have flipcharts upon which people can write “Please repeat session X!” and “Yeah, please!” If there’s enough interest and a willing session organizer, the session will be repeated.

Request: We’ll have quite a few people floating around the conference who can show examples of technique X (not necessarily a testing technique). We’ll have more whiteboards where people can request sessions built around examples of techniques. This is somewhat like Open Space, but oriented toward showing rather than telling. For example, I’d be happy to show my graphical workflow tests in action—if people want to see it.

Take that a step further: I had been thinking of two types of submission: one that comes into the submission system while we passively wait, and one where we actively invite specific people to enter something into the system (or, possibly, simply invite them to come and do their thing). But why should our paying audience wait to see what other people want to push at them. I want our audience to pull by proposing sessions they’d like someone else to perform. Then it’s the producers’ job to find people who can satisfy the demand.

For example, suppose some people think a session on improv would be good, and they make that argument <somewhere>. Then it becomes my task to contact the three or four people I know who’ve done improv and get them to work up a proposal. (In fact, I’m going to do this without prompting.)

Another idea is “Reality Theatre.” As I’ve mentioned before, many groups can’t envision what a good standup or planning meeting is like, not just by reading descriptions in books. Similarly, the buzz and activity inside a good Agile team is palpable but hard to describe in print or by waving your hands around as you talk. So I would like the Example room to hold the world premieres of short documentaries of actual teams doing actual things. (Real video, edited, with expert commentary.) We may be able to provide some production assistance. Maybe we can get a company to donate prizes.

So that’s what I’m looking for: nothing that’s a safe bet. Watch this space for more.

Many people over the years have attended my talks partially or entirely to hear about cows. About cows with portholes, about cows eating car batteries, about the mystery of what the omasum is for. I got those stories from my wife, longtime professor of Food Animal Medicine, and tried to deftly tie them into the ostensible topics of my talks.

That era draws to an end today. Today she becomes assistant dean for Academic Affairs and Curriculum, responsible for developing clinical skills labs, riding herd on all the courses and curricula committees, figuring out how to tell if students have learned what they’ve supposed to, and so forth. Stuff to do with learning and humans: what relevance could it have to software development?

But all is not lost. She remains director of the campus-wide Agricultural Animal Care and Use Program and Attending Veterinarian for agricultural animals. If you want to do fiendish experiments on cows, pigs, or chickens, you have to get past her first. So the scope of stories broadens, in a way. For example: chickens, she tells me just now, like to play with strings. If you want to make a chicken happier, hang a string in its cage. They like some color strings better than others.

You may hear more next semester, when she teaches VCM510, Science of Animal Well-Being. To learn about the relevance of chicken strings to us, you’ll have to attend my next talk.