Fri, 05 Dec 2003
Acceptance tests are things to point at while having a conversation. The speakers will be testers, programmers, and business experts. The neatest surprise with FIT, to my mind, is the way you can turn a web page of tests into a narrative. I've mislaid my good example of this, but here's a snippet of page about an example Ward often uses: a bond trading rule that all months should be treated as having 30 days. (Note: I don't know if the following is correct - I was just playing around with FIT, not writing a real app.)
The page is organized as set of special cases, each with a brief description followed by some checked examples. I really like this style: it's an easy-to-write mini-tutorial for the programmer and reader.
However, when it comes to tests that are sequences (action fixtures), I find that the tabular format grates. The table, instead of being a frame around what I read, is something that intrudes on my reading. It may be that I'm too used to code.
Another difficulty is variables: such useful beasts. Think of constructing a circular data structure. Yes, you can write a parseable language to do that (Common Lisp had one, as I recall), but to my mind it's simpler just to create substructures, give them names, and use the names to lash things together.
Or consider stashing results in a variable and then doing a set of checks. Or comparing two results to each other, where the issue isn't exact values but the relationships between values.
You could invent variables in the FIT language, but you're starting to get into notational problems that scripting languages have already solved. That way lies madness (after inventing loops and subroutines and...)
And yet, there is the niceness of HTML format. I've been toying with the idea of a free-form action-ish fixture that looked like this:
Running the test might yield this:
Here, I'm following
RoleModel's lead in
using Ruby as a somewhat customer-readable language. (<rant>And I
also fixed the backwards order of xUnit
This format also allows for a mixture of scripting and tabular styles. I have some tests that look like this:
You'll notice that I indent the asserts. That's because the tests (especially the longer ones) do a lot of starting, stopping, and pausing of various interacting jobs. It's too hard to see what's going on if the the asserts aren't visually distinguished from the actions.
Nevertheless, it's still pretty ugly. I showed it to a customer-type (my wife, who knows no programming languages). She understood it fine after I explained it, but it didn't thrill her. This might be better:
The fixture synthesizes all the cells into one Ruby method. Is this better? (I'm not a particularly gifted visual designer, as anyone who's looked at my main website can tell.)
A final thought. I've read a couple of papers on intentional
programming. (Can't find any good links.) It didn't click for me. I think it was the
examples. One example had a giant embedded in some
The thing is, I found the mixture of C and mathematical notation
jarring. Is the equation really clearer - to a programmer
immersed in the app - than
But when we're talking about tests, we have two people who have very different cognitive styles, goals, and backgrounds reading one text. I can envision a common underlying test representation that can be switched between two modes. One is the "discuss the test with the customer" mode. The other is the "see the test as executable code" mode.
Perhaps Intentional Software will take up Martin's challenge. (If so, my consulting fees are quite modest...)
1 The equation shown isn't the one used in the paper, not unless there's been an amazing coincidence.