Expressing Business Rules

I arrived at XP2005 yesterday to take advantage of the tutorial track that takes place before the "proper" conference gets under way, and I'm glad I did. Rick Mugridge's tutorial on Expressing business rules with story tests was well worth getting out of bed for early on a Saturday morning. As well as covering the basics - what is a business rule? what is a story test? what is Fit? why use FitLibrary? - Rick also passed on some observations on his experience of using story tests in Agile software development:

• Story tests are as much a communication mechanism as a test mechanism
• It takes both analysis (formalising the business rules for the system) and synthesis (considering the impact on the business of the system) to create good story tests
• The language used in story tests (close to Eric Evans' idea of a ubiquitous language) needs to be open to change, e.g. when understanding or business circumstances change
• Copy and paste between story tests is the sign of a missed abstraction
• Treat tests in the same way as you would code: pay attention to naming tests and refactoring them
• Procedural story tests can often be expressed more clearly and succinctly as a set of declarative tests
• Testing a system through the UI is not the same as testing the UI or testing the system