Hi Andy, You actually brought up a great point that I think jbehave team should write a document about. Dan? :)
Stories do drive the behaviour. However, stories are driving the behaviour of the *application*, while the behaviour classes are driving the behaviour of the matching *class*. That is what I mean by different level. When going done to the code that are being executed, they are the same class. But they are executed at different level. For example, let's pretend that we don't have the HashSet class in Java and we have to implement it because we want to support the feature that when the user type a list of email addresses that can have duplicates, only one email can be sent per address. So at the story level, the customer just write a story that says Given news broadcast page When I entered email "[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]" That [EMAIL PROTECTED] receive one and only one email When developer implementing this story, he will need a behaviour class for this HashSet class that he wants to write (add, iterator as the minimum to finish the story). He will probably also need to create or update the existing behaviour for each classes that he needs to touch, like one for the class that handles the email sending to make sure that it is not sending duplicated email, or one for the code behind the UI to make sure that the duplication is removed, etc. The user story does not exercise these behavour classes that the developer wrote for this story because that would be too much detail. The user story does and should exercise the production code that the developer has written. Please let me know if this explanation is better. You feedback will be used for us to update the document online. Cheers -- Shane http://www.shaneduan.com On 4/5/07, Andy Zimmerman <[EMAIL PROTECTED]> wrote:
On 4/5/07, Shane Duan <[EMAIL PROTECTED]> wrote: > Hi Andy, > > The short answer is "Stories are not associated with the behaviour classes". > > The full answer is that they are on two different levels. Maybe I'm misunderstanding the thrust of jBehave then. Hmmm. > Behaviour classes are written by developers through BDD practices. > They are the way that developers can make sure that they are writing > high quality code yet not spending too much time on up front design. > You can check out any TDD article for the full description. That is > why it is in Java, because that is the language developers are most > comfortable with. This part I have a pretty good handle on, but thanks for the overview/clarification. > The stories are used for the customers to write the acceptance > criteria for the stories that development team has committed to > implement for the current iteration. Developer will write classes > that will support running the story, but the stories themselves will > be written by customer (or anyone with the authority to say "this > story is done"). That is why they are in plain text because we cannot > expect them understand Java. This kind of testing is called > acceptance tests, here is another favor of it (http://fit.c2.com/) I guess I understand the Story runner even less than I thought I did then. I *thought* that jBehave was lending itself to increasing the transparency between the levels of this process: The Customer drives the Stories > the Stories drive the Behaviours > the Behaviours drive the Code. So the "driver" of each level is the validator of the underlying level, i.e. the Behaviours validate the code, the Stories validate the Behaviours and the Customer validates the Stories. But if what you are saying is correct, that there *is* no connection from Stories to Behaviour, then I don't understand why the Stories are executable at all. > Hope this helps Unfortunately not. I think I've confused myself further. ;-) > Cheers > -- > Shane > http://www.shaneduan.com Thanks, Andy
--------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
