Fork me on GitHub

Wednesday, May 27, 2009

Business Reabable Tests or Writable Tests?

There have always been a quest for helping the business users or clients to write tests for their applications directly. Elaborate frameworks like FitNesse, Cucumber, Concordion have been constructed to help writing tests in English like language. The reason being business experts know about the domain, the problem they want software to solve are in the best position to set the expectation of the software which is being developed. But there are several catches to business experts directly writing tests.

1) Acceptance tests are much more than verification tests. While building acceptance tests with the team the business experts discuss with the team to create these tests. As a result of these discussions the knowledge and understanding is being shared with the team helping the team understand the domain and the problem better .I think this is a very important for the team as well as to the evolution of software being built. If the users are able to build tests by themselves it may lead to a situation where they create the tests and just hand it over to the team as validations. Although the validation is important the knowledge sharing part may be missed.

2) This reason may not be application for all the business experts. Writing tests is also writing code. Tests tend to use English like language but they are never natural language. They are just higher level abstractions from code. So they still have some conventions like naming, casing, passing arguments to follow when writing these kinds of tests else they will not work. Also normal program practices of refactoring may apply in this context as well. So to do this effectively I think it is better for a business expert to work with a technical team to write these test. (On a different note I believe that tests are written in domain language are better than English like language. Capturing the domain part is important not the English part)

So as they say in DSL world, it is good to be business readable tests so that business experts can actively participate and help to build and use them. Business writable tests are not impossible but difficult for now. Some of the concepts in programming world may pave way to this concept in reality. Things like Language Oriented Programming, External DSLs and Intentional Programming may help us in future to work with business experts to construct tests. But it is good to keep in mind the fact that it is sharing of knowledge important for building better software and tests facilitate to do that.

No comments: