An example of Acceptance Tests as Boundary Objects.
Once I was consulting for a shop that used Ward Cunningham’s FIT testing framework. When you used FIT, tests were written as HTML tables. Tables are a nice format for lots of tests. They’re *scannable* - you can quickly review a table to see how one test differs from its neighbors. Because of that, it’s harder to leave out special cases.
In this particular shop, tests were written by independent testers in conjunction with the product owner; he’d talk with at least one tester and at least one programmer to lay out the main cases. Then the testers would write those ideas down in HTML tables, but also add other cases – often finding odd combinations of inputs where the product owner would have to decide what a sensible output would look like. Then the programmers would change the product to match the tests.
That all seemed to be working well.
But one time I was walking out of the team space at the end of the day when I overheard a programmer say “Now I have to rewrite the FIT tests in JUnit”. That was weird enough that it brought me up short: I stopped to ask him what he meant.
Here’s the story:
The testers were used to programming test-first. They wrote unit tests in Java, ran them with the JUnit framework, debugged them when they failed unexpectedly – and did all of that within their development environment, Jetbrain’s Intellij IDEA. They had a nice tight feedback loop.
The acceptance tests, though, were written in HTML, not Java. Working with them meant stepping outside that familiar feedback loop. That was awkward enough that this person took the HTML tests, translated them into Java, ran them under JUnit, got the code working, then *additionally* did the work of making the equivalent HTML tests pass under the FIT framework. That extra work added no value.
So: No no no, was my reaction. Ahh! Duplicate work. I suggested that we take his JUnit tests and edit them to make them more human-readable. So, for example, we didn’t use Java’s stupid convention of smashing words together, separatedOnlyByCapitalLetters, to make human-UNreadable names. We instead separated_words_with_underscores. Easier to read for a product owner (anyone, really). And we violated coding conventions to make the code look more tabular. Then we called the product owner over, explained what we were doing, showed him the tests, told him to ignore commas and semicolons and funny characters like curly braces, and asked whether the tests made sense to him. They did.
It was not long after that that the majority of tests were written (by the testers) in a sort of pidgin Java. The programmers would take those tests, fix the syntax errors, and code away just as they liked.
I think that’s a good example of how people can coordinate effectively using Boundary Objects. We called them acceptance tests, but some might say they’re *really* unit tests. To which I reply: **NO**. We will not have this conversation. Those things over there mean different things to different people, and That’s Fine. We don’t need a single universal definition. What matters is this team, getting the work done, together.