Wednesday, September 12, 2007

JavaZone 2007: Style and Taste in Writing FIT Documents

This session had Steve Freeman (of jMock fame) and Mike Hill tackle common problems with FIT. One of the most interesting sessions today, I think.

Example-driven development

Examples force people to be concrete. The next step is to automate testing your system based on these examples. FIT is one way to do this.

The point of FIT is communicating with the customer. Other tools can be used, such as JUnit with a DSL which is easier for an analyst to understand.

Communication trumps testing

Copy-paste of a procedural FIT table can make it hard to understand what the difference is. Can be converted to declarative table where each row or column is its own example. It's harder to refactor FIT tests since there's no IDE support, this means you must be more disciplined.

Having a mega-table with lots of input and output columns ("Tangled tables") can be practical for professional testers, but doesn't communicate clearly. It can be broken up into different, smaller tables. Abstractions that developers come up with can feed back into the business language. Can also be easier to change smaller tables. As in XP, why is something a comment, instead of runnable code?

Web tests in FIT: should hide implementation details such as field names, "url" lingo, etc. Use a domain language which makes sense for your business instead.

FIT in practice

When you work on a project, you become expert on that project. Experts have their own common language. Build a language within your team to encourage a common understanding.

Make test failure easy to understand. The tests shouldn't just satisfy the business side, but the developer side as well.

Apply all good code practices to the tests also: refactoring, etc.

Collaboration problems can affect test quality negatively; if you're trying to avoid collaboration and skip refactoring because of it, you've got a problem.

Agile teams which adopt FIT documents as documentation can end up in a waterfall-like passing of FIT documents with no real dialog.

If the analysts are not very keen on FIT, try to publish the test result and the documents so it's easy to access.

Word documents vs. Fitnesse: Depends on the organization and the analyst users.

No comments: