malvasia bianca

Acceptance testing has not been one of my fortes. Honestly, it took me a long time to be convinced by it – why isn’t unit testing alone enough? I’ve been caught out enough times by acceptance tests which I put off writing and which, when written, turned up bugs, that now I’m pretty religious about writing them. But, even so, I can’t say that I still completely “get it” (and it may be that those bugs are just places where we didn’t do as good a job of unit testing as we should); in particular, I still have yet to be in a situation where I really need acceptance tests to communicate with the business side.

Anyways, it seems like all the trendy agile people these days are using Fit (usually combined with FitNesse) these days to do their acceptance testing. And there’s a new book out about it, Fit for Developing Software; it’s gotten good reviews, so I gave it a read.

It’s a very good book; extremely readable, and I suspect that it should be readable by business types, not just programmer types. In fact, the entire first half of the book doesn’t talk about programming details at all: it talks about how you can use Fit to enable business people and programmers to clearly communicate their expectations, and the wonders that will result from doing so.

Anyways, what Fit does is let people from the business side (the Customer, as XP would say) write automated tests in as simple and natural a way as possible. The form that tests take is tables (e.g. on a wiki page, though you can use straight HTML or even Excel, if you wish); the tables give inputs and expected outputs, along with enough information to enable programmers to write a bit of glue code (a “fixture”) saying how to interpret those tables. And then you can easily run the tests expressed by those tables; it will color the cells corresponding to expected outputs either green or red, depending on whether or not the tests passed!

There are two basic kinds of tests: ones to test calculations and ones to test events. The former look pretty much as you’d expect: an example might be an application handling rentals, where you would want to calculate the late fees based on the kind of item, the rental period, and the time that the item was returned: you could then have a test with four columns, where the first three columns gave that data, the fourth column gave the expected late fee, and each row was testing a different late scenario. Then the cells in the fourth column would turn either red or green, depending on whether or the code calculates the late fee as expected.

The others are action based. I’ll give an example from the book, using vertical bars to separate cells, since I’m too lazy to figure out how to do tables in HTML:

| fit.ActionFixture |
| start | BuyActions |
| check | total | 00.00 |
| enter | price | 12.00 |
| press | buy |
| check | total | 12.00 |
| enter | price | 100.00 |
| press | buy |
| check | total | 112.00 |


So the ‘check’ rows are ones that test if some output is as expected; the other rows represent actions. (Except for the first two, which set up the fixture.) You can think of this as, say, representing a user entering data into a form on a web page, clicking on buttons, and looking at the updated web page, and you could even write a fixture that did just that; if your application is architected correctly, then the web page details will be abstracted away in a presentation layer, and you can hook your fixture into a somewhat lower layer, making the test faster and more robust to change.

Some things that I found interesting:

• I’m not used to seeing action-based tests expressed that cleanly; it’s definitely a vision to aspire to.
• I’m used to thinking that “acceptance test” equals “end-to-end test”. You can use Fit to do that (and probably should, to some extent), but Fit also allows the customer to write tests that get a little closer to the underlying models. Which is good; it makes for faster tests, and for clearer discussion of the underlying issues. In fact, some of the Fit tests look pretty similar to unit tests; I wonder how much unit test / acceptance test duplication turns out to be a problem? As problems go, though, that one is not so bad.
• I don’t want to go into details here, but I was impressed about how easy it looked to write the fixtures connecting the tests to the underlying code base.

I’m not about to lobby for switching our current project over to Fit, and I’m not sure Fit is the best fit for many of the issues that my team has to face. (We have some hard testing problems that are different from what is front-and-center in most XP environments, I think.) But I’ll definitely keep it in mind in the future, and the reminder that people from the business side might be interested in non-end-to-end tests is a good one.