Contestation is a great when it comes to Agile because it causes us to think and make certain what we are doing is sound and valuable. I understand Scott’s concern having been on the evangelistic band wagon for a while it is harder to undo misunderstood concepts than it is to bring forth new ones. TDD has served the Agile community for quiet sometime and has proven to be an invaluable practice. We as a community have to be very cautious that the values of Red, Green, Refactor that lead to a supple design, persist in any new Agile endeavor.

Courage is one of values of eXtreme Programming and is often executed in a number of ways. But even beyond XP, courage I believe is founding principle of Agile as any practioner can attest too. Stretching the boundaries of software engineering requires great courage but an equaling harmonizing principle is Humility which I value much higher than courage. Learning to balance both is an art form in and of its self.

I am curious on how the traceability mechanisms can be damaging to BDD?

I don’t know if I captured this in the post but what I am trying to do is capture the contextual inception of the behavior. To me BDD is nothing more than TDD with a contextual nature. Sure the TDD covers the functionality and design but are the behavioral aspects of the domain applicable within the contextual nature of what it was intended to solve?

Given {some context} this object {should behave} {this way}

But what gave “this object” that {context} and this is where I feel one of NBehave’s greatest strengths lie. It allows any team member to query the code to determine where the context originated from. There have been plenty of times during the maintenance phase of a project that we enhance a service or entity and can’t remember why it behaves a certain way and should it? We ask the business and they can’t even remember why? Don’t get me wrong the site functions as expected but when you have a solution with over 40 projects and over 6000 unit tests, management of the test takes on a whole new dimension.

One would argue, does it matter that you can’t remember since your code works and the acceptance test pass? Simply create a new story that changes the behavior and work through the behavioral aspects of the new story. To that statement I would answer, it depends. To save time in a modeling session we revisit older models to understand the changes to new enhancements. Some features are so huge that they were comprised of 30 stories or more to complete. At times we had to figure out why certain functionality was behaving a certain way and looked to the old story cards to provide us detail on the value aspects of the feature. How often did we do this…maybe once an iteration. Was the return on looking up the old stories that high? Sometimes. Did it help? Yes!

The side effect to this is that it generates traceability for me! Yes selfish me!! LOL and your right Scott no one specifically told me that I have to map the stories in the source code to do this. For me it just makes sense. The ability to capture the inception of the behavioral context of the domain is huge. So your hat is safe. 

Having said that, you could just as easily wrap the constructs of the story narratives and behavior within a standard Unit test as most BDD practitioners are doing today.

I have to say that i felt in love with the concept (BDD), it is true that it has not reached its potential, but i applaud the fact that practices and experiments like these are carried out; how else would you be certain you’re doing the best you can do to the best of your knowledge if these concepts are not constantly contested? and although i understand where Scott is going (and i personally don’t entirely disagree), we (at least i) have to keep trying to find alternatives that at least “make sense” in software development.

My first personal weeks learning and experimenting with both camps have been intellectually fantastic, there’s a lot of debate and concepts on the table and there’s more to read, but hey, it was not until i tried BDD on a project that i personally realized of TDD’s value for me and my team.

Thanks to both of you who definitely help the software community by bringing these open discussions to the table.

I personally hope the BDD initiative is continued and matures… if fibonacci was right, the next iteration should be exponentially better

You’re trying to force traceability onto processes and artifacts that aren’t intended as traceability mechanisms and possibly damaging them in ways that might remain inaccessible while doing so.

I’ll eat my hat if there’s someone in your compliance and auditing organization who has specifically told you that you need traceability from user stories to code in the form of the NBehave API and a specific abstraction that represents a User Story.

I appreciate the research and development aspect of what you’re trying to pull off, but you’re performing surgical experiments on parts of the agile practices organism that should be kept healthy at all costs while you’re depending upon them for the life and health of your project and your team.

You can find a good place in your architecture (not necessarily the software architecture) to introduce an anti-corruption layer that supports compliance but insulates your programmers from the incursion of its insidious tendrils into code artifacts.