Chris (Chris Matts) and I have been discussing JBehave with Jen Stille, one of the other ThoughtWorks BAs.
Chris explained that for him JBehave supports his view of Business Analysis that is based on Kolb's model of learning. We start with concrete examples from which we create a model. We then add new concrete examples and test our model against them. We reflect on whether the model satisfies the concrete examples or whether we need to upgrade the model. Traditionally, this model is kept and the concrete examples are lost. JBehave captures these concrete examples in the acceptance criteria. The model is of value as it forms the ubiquitous domain language that underpins the JBehave stories.
I think the key objective of JBehave is to help people get TDD (most people don't). I think writing tests in terms of expected bahaviours, while only a very small change from TDD, achieves the same ends in a easier to understand fashion. However, if its going to take-off within the analysis community, the challenge is going to be managing the number of states (or 'givens' in JBehave speak). In a simple system it can definitely work, but so will just about any other analysis technique. In a complex system with a huge statespace, it's success will depend on how effectivley we can manage the list of starting states.
Chris says that one of the powerful aspects of JBehave is that it deals with abstract (model) and concrete. For example,
GIVEN account is overdrawn ( balance = -50 ).
This is unlike traditional modelling which only works on the abstract and "traditional" test based approaches like FIT which on work on the concrete.
Posted by timv at December 14, 2004 4:16 PM