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
