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.
Well, now I have. Here’s a set of tests for business rules similar to the ones the client uses (obfuscated so that the company can’t be identified):
I’ve written a pile of code to make those tests pass, doing some fiddling with them along the way. Subjectively, making a small allowance for bias, I’m thinking it’s been about the same pain as editing HTML. If I wasn’t a complete novice at TextMate, it would probably be less. (Surely TextMate must have an equivalent of a Back button so that you can flip between files easily even if you haven’t dragged the tabs to be next to each other.)
I even think this test isn’t horribly unreadable for a non-technical reader once you tell her to ignore the starting and trailing gobbledeegook, underscores, and quotes. (And it wouldn’t be too hard to write a script that did that for her, or even one that generated HTML.)
The output of a failing test is much less appealing to a product director, but it’s more appealing to someone actually working with that output (a programmer or tester): it’s got a stack trace, probably one that’s clickable.
This approach would encourage people to write test fixtures in Ruby, which is considerably faster than doing it in Java or C#. And it makes fixture-writing accessible to the well-read tester. In this particular case, the app communicates with the outside world via XML over the network, FTP files, and a database, so there’s no need to link the fixtures into the code. If it worked through a GUI, some remote procedure call interface would have to be added, but I persist in thinking that’s not too much to ask.