• A key goal of these tools was to allow the business side of the house to write acceptance tests, or at least be able to read acceptance tests and agree that they are reasonably accurate and complete.
• That mostly didn’t happen.
• The tools became increasingly programmer centric, making it even less likely to ever happen.
• This ultimately leads to developers having to support two test streams, acceptance tests and unit tests.
• Developers ain’t keen, so they tend to drop one.
• The one they drop is usually unit tests, which Uncle Bob strongly believes is the wrong one.

I can totally follow this train and see where this can lead to Bad Things. That said, however, I must say that I’ve found tools like Cucumber, Aruba, and Geb very useful in my university classes.

In the simple case, tools like Cucumber and Aruba often great for writing executable specifications for class projects. This is somewhat similar to the goal of having the business team write the tests, but obviously I’m in the fortunate position of being a developer as well as the person writing the specs. It’s very nice for teaching, though, because I can specify what I want them to do without over-specifying how they do it. Unit tests will typically need to reflect all sorts of design decisions, and part of the point is often for them to work through the design, so it’s nice to have tests that both they and I can use to sanity check their solutions without tying us all down to a particular set of design choices.

In the more complex case, our students have often found these tools to be extremely useful for their own tests, especially when they’re struggling with a new problem domain and/or a new set of languages, tools, libraries, etc. In many ways a unit test requires the ability to envisions at least some of the structure of the solution; you have to be able to see where a unit will be. If they’re writing their first web app from scratch, using languages and libraries they’re just learning, it can be really hard to know what the first test might look like. So they tend not to write it, instead doing “spikes” to try to understand how the pieces work. These “spikes” go on and on, get bigger and bigger, and often become the project instead of being thrown away, and none of that development was supported by any sort of tests.

While it can be really difficult to envision units in a totally new space, hopefully they can understand use cases and user behavior. Tools like Geb allow them to specify what the tool should do without (yet) understanding what the insides will look like.

In many ways the two cases are quite similar: A.T./BDD lets us write tests without committing to design decisions yet. In the first I don’t want to dictate those decisions, and in the second they simply don’t yet know what those will look like yet, but either way we get to specify what is hopefully some useful and significant behavior right away without getting bogged down in those issues.

In a perfect world, they’d start writing unit tests for key pieces of internal logic as the design develops, especially for units whose behavior is complex enough that it’s hard to catch all the combinations through the user interface. That doesn’t always happen, but eventually the instability of the UI often drives teams to bring some of the testing from the UI into more stable areas of the code.

So, do I think every project should start with Cucumber tests? No, definitely not. But I do think they’re damn useful in certain circumstances and I’m quite glad to have them.

Jamie Beck and Kevin Burg have made some very cool and wonderfully subtle animated GIFs that may possibly be the most interesting use of that technology that I’ve ever run across. Sadly, a lot of what they’ve done with it isn’t that exciting (lots of clothes and hair moving gently in a breeze), but there are a few examples (such as the one above) that are real gems. If you’re interested you might check out “Far Better Than 3-D: Animated GIFs That Savor A Passing Moment”, a nice article on their work (which is I where I learned about it). You can also see more of their animations here and there.

It’s interesting to see in what ways various organizations do and don’t “get” these changes. Sadly, the U in general and the Morris campus in specific, for example, aren’t generally real on top of things when it comes to modern web technology. What’s particularly frustrating is the U’s unwillingness to work with and empower their users to help generate and manage content and value. Big Web 2.0 successes like Google and Amazon, Twitter and Flickr are all about leveraging user generated content. The U has its little fits in that direction (the U of M wiki, the UThink blogs), but they’re always peripheral to the life of the University, always in the back alleys instead of on the front page.

The ThoughtWorks discussion runs about an hour, and they divided it up into three chunks for podcasting. Unfortunately they haven’t released a new podcast since last July, so it appears that I’m late to the party and the party may be over. I look forward to listening to their other podcasts, and I certainly hope that they start making new episodes sometime soon.

If you’re interested you can find all their podcasts on the ThoughtWorks What We Say page through either RSS or iTunes.

Whether you’re coming to EuroGP or not, we’ll be “turning on” the Lulu site Wednesday, so people can buy printed copies and download the PDF for free. As a teaser, the poster above contains the entire book — just really, really small! If you click on it you can see it a little bigger, but I still recommend waiting a few days for the Real Deal.

Thanks to Riccardo for using some of his major LaTeX mojo to create the mosaic of all the pages, and to Jess and WeatherGirl for their suggestions regarding the design.

Yup, crazy as it sounds. Eyetrack has collected some nice user data, which they summarize in “What We Saw When We Looked Through Their Eyes”, which is then reorganized in “Scientific Web Design: 23 Actionable Lessons from Eye-Tracking Studies” over at VirtualHosting.com.

At some point I should go through these with some care and think about how they apply here. I tend to generate pretty cluttered designs – I keep trying cram in the information, and I end up with more Redmond than Google, I’m afraid. Maybe I should rethink that a bit.

This is hilarious. They walk you through the stepwise changes if Redmond had designed GMail. Thanks to John Naughton for the pointer.

Paul Rand is responsible for a number of iconic pieces of graphic design (e.g., the classic IBM logo), and this is a nice short film combining examples of his work with short snippets that I assume came from interviews with him. Some great quotes include

A work of art is realized
when form and content are indistinguishable.
When form predominates, meaning is blunted,
but when content predominates, interest lags.
But the genius comes in when both of these things fuse.

and

Don’t try to be original, just try to be good. That might sound naive, but it’s true.

There’s a neat bit where he goes over the “language of form”, listing important concepts like texture, shape, balance, and tension. It would be fun to sift through my photographs and look for a good examples of each of these. And probably revealing as well, since I strongly suspect some of his terms would be much better represented in my images than others.

Tip o’ the cap to Panopticist for the pointer via 37Signals.