I spent the day in the London ThoughtWorks office.
I was lucky enough to spend most of that day with Joe Walnes and Dan North.
Dan and Joe explained CRC Cards to me as a way of introducing JBehave. Dan then spent a couple of hours working through an example of behaviour driven development. He also showed me how JBehave makes use of Mock Objects. "VERY nice." to quote Joe.
We spent lunch discussing these things. Joe mentioned that Rebecca Wirfs Brock now calls them RRC cards... Role-Responsibility-Collaboration Cards. The role is the same as the view in model-view-controller or my use of metaphor
My interest in JBehave is not from a developer perspective. Rather I am trying to work out how we can apply the technique to recording analysis. I am keen to see an analysis tool that it used to capture the concrete examples that we use to develop our business models. I am also keen to see Eric Evan's Domain Driven Design work linked to the work of the business coach. JBehave also makes it easier to do Rebecca Wirfs Brock's responsibility driven design
I spent my commute thinking about it and I believe that Dan is on to something. For Dan, one of the most important aspects of JBehave is that it encourages you to focus on what the class SHOULD do next. This makes the behaviours more easy to read and meaningful in the domain language. It says what the system should do. What is missing from the should is the context. This is provided by the Mock Objects.
However, rather than the class SHOULDdoSomething, it really should read. SHOULDdoSomethingGivenThisContext. The SHOULD really refers to a conversation. Given this context (Provided by MockObjects), the Class/System/Component should have the following conversation. Use cases try to capture this conversation but they lack the context. The context in BDD is provided by Mock Objects. We need to pull all this together.
Given this context (Initial specified state for the system which is provided by Mock Objects for BDD and will need to be provided by something else for Behaviour Driven Analysis), the system should have the following conversation. The conversation is the Use Case. Even better to use stories and have the Business Coach pair with the developer to specify the conversation. The conversation is the message passed to the system and the system's response.
I definitely see the merging of the Business Analysis and Testing role. I better add Brian Marick to my list of links.
Sorry if this is all a bit jumbled, I am trying to get it all straight in my head.
I think I'm finally getting the object paradigm after eight years. It took me five years to understand the relational paradigm. Perhaps I'm slowing down in my old age.Posted by chrismatts at August 23, 2004 8:07 PM