Acceptance tests should reflect customers’ perception of when the job is done, so they must be defined by a customer or a business analyst. That still leaves us with a question who should translate that definition into FIT/FitNesse tables. There was an interesting discussion on this topic at the XPDay 2007 conference in London, during a workshop called “Working With Customers towards Shared Understanding”. Several participants noted that if developers are left to do that on their own, then tests turn out too technical and task-oriented. Acceptance tests are more effective if they are focused on larger activities and expressed in the business domain language. FitNesse allows customers and business analysts to write tests directly without involving developers, but this may be a step too far, as customers often forget about edge cases and focus only or general rules.
Antony Marcano, one of the maintainers of TestingReflections, spotted nicely that the conversation during test writing helps a lot to clarify the domain and enable developers to understand the problem better. If tests are written by customers on their own, then the value of this conversation is lost. So, ideally, a developer and a customer representative, or a business analyst, should write those tests together.
