Exploration Through Example

Many of the tests that currently use browser-driving tools like Selenium, Watir, or Silk could use different implementation technologies. In the rest of this note, I describe the pros and cons of browser driving, HTTP driving, the Rails variant of HTTP driving, and app-layer driving.
(more…)

Back in the day, I was heavily associated with the context-driven school of testing. I still honor it, but I do assert that Agile is importantly different. It is context-driving, not context-driven.

That is, probably the key question in the context-driven school is “given my context, what’s the best thing to do?” (See the two-project example at the link above.)

The question in Agile is much more “given my context, what should I change about it to allow me to work more as I please?”

Obviously there’s overlap, blah, blah, blah. But the different emphasis leads to different actions leads to different projects. At least in my case.

UPDATE: Since I link to this post occasionally, here’s an email I sent once that adds a bit to it:

I’ve come to think of Agile as /context-driving/ rather than /context-driven/. This comes up in the perennial debate about whether there should be 100% test automation. A lot of that debate is tedious and silly, but there’s an important facet that too often goes unmentioned. Programmers have reasons for wanting 100% test automation, important among them that programming is less stressful with test support. It is a fact in many projects and code bases that some proportion of tests programmers would like to have automated are not worth automating by any dispassionate standard. The historical context-driven-testing answer to that problem is to accept it and find the best possible blend of automated and manual testing (and to make sure that both are done well). The programmers’ context-*driving* answer is to change the context so that the economics change to make 100% automation economical.

Now, that attempt to change the context could work, or it could not. As it turns out, it’s worked surprisingly well across a broad range of problems, which makes me want to continue pushing in that direction, rather than growing up and admitting some things are impossible.

Earlier in the series:
Controller channels

“Omit needless words” is number 13 of Strunk&White’s elementary rules for composing English. It’s a pretty good rule for composing tests, too, but not followed often enough. Let’s rewrite an example of the sort of test I often see.

(more…)

I am going to write a document called “The Mechanics of Business-Facing Automated Tests”. I’ll be posting drafts of the different chunks here, hoping that you’ll help me improve it. I’m interested in improvements to the ideas and the flow of explanation rather than line-by-line or word-by-word improvements. Thanks.

The sample application is only a realistic sketch. It pretends to be the server part of a system used by travel agents. For my own convenience, I wrote the application in Ruby, but I’m treating it just as I would were it in Java. The tests are written in Ruby for the reasons I gave earlier.

In normal use, the application is a server that communicates with a client and with airline servers. The server communicates to the client via XML messages over a network. To communicate with airline servers, it drops files on disk to be picked up by FTP. Airline servers deliver files in the same way.
(more…)

I’m not the only person thinking of writing Fit-like tests in Ruby. Zenspider had the same idea first.

Elisabeth Hendrickson has a nice cheat sheet that will help you get ideas for tests.

That title seems like a good motto in general. Here’s a specific instance.

I was on a short consulting trip recently. We talked about Fit. I said the two things that I’ve said to clients at least ten times:

“I recommend using Fit when the product director wants to read the tests or when the data is naturally tabular. If the product director doesn’t care or if the test is a do-this-do-that-check-this type test, I’d rather you used xUnit.”

…

“There are no decent HTML editors. The most tolerable I’ve found is OpenOffice, but they’re all a pain when you want to modify tables.”

There’s a contradiction here. If the product director doesn’t care, why would you write a tabular test in HTML? Because using xUnit means you have to keep columns aligned, and that’s a pain. So use HTML and have the browser line up the columns. But I just said that editing HTML is also a pain. And I never gave much thought to which is the greater pain.

(more…)