Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Mapping BDD

In my last post I offered a concise snapshot of how I’m practicing Behavior-Driven Development. Based on feedback, it was probably a little too concise and meta to provide any kind of valuable takeaways or discussion points, so I’m going to unpack what I said there over a few, more-specific posts.

Iteration I/O

I’ve experienced success with BDD as an integrated component of a larger suite of Agile practices. Specifically I see BDD as a mapping activity between user stories and code. Think of an iteration or sprint as a pipeline: you put stories in at the beginning and the necessary code comes out at the end. The BDD process starts before you put stories into an iteration; you provide acceptance criteria (in many forms, more on that later) in order to understand the nature and implications of the story. These acceptance criteria then serve as a context for the developer in modifying a codebase.

To be clear: specifications describe code and a developer specifies the code.

Think of story structure, in this light, as an aggregate root. One story has zero-or-more acceptance criteria. Acceptance criteria come in many flavors. Falling back on the object oriented metaphor we can say that a specialization (or subclass) of a criterion is a “User Interface Prototype.” We can define another specialization as the “Scenario.”

Now we’re all probably familiar with these scenarios. They’re the ones given in Dan North’s introduction (and many others), something like:

After depositing $100 dollars into an Account with a balance of $0, the balance should be $100.

Sidebar: you’ll note that I’m not a big fan of the Given/When/Expect formalism or even the less restrictive when/then format. Story scenarios should read like Plain Old English (POE). Well maybe not plain OLD ENGLISH: whence ye olde account hath taken deposit.

I’d contend that these are bad examples, the plague of our industry. You might find this exact scenario appear in an executable class specification several times. It might surface as a specification of an Account entity in a model. It might also match a specification of a controller pattern in a presentation layer. Are the two the same? Nope. Would you express that surface duplicity in the story. Surely, no.

Furthermore we’ll have a number of technical or infrastructure things we need to do. Our end user won’t care about that. Sorry, you can try to make them, but they won’t. They certainly won’t author those specifications. It’s up to the developer, when working on a story as a vertical slice through a system or through multiple components in a non-monolithic application to author specifications while working. The process of writing specifications continues past the process of estimation and admitting a story into an iteration.

So, yes, mapping is what we’re doing here. Mapping and continually adding specifications. We’re mapping specifications that came in to an iteration to things like the presentation layer and the domain model. We’re developing specifications and subsequently mapping them to infrastructure bits to fulfill a complete, working feature and we constrain ourselves to just doing enough to make that feature “potentially shippable.”

Define: “Behavior” and “Specification”

What exactly is a behavior? Is a behavior a feature? I vote no. I like to think of a behavior as the smallest possible expression of one (and only one) thing that a code artifact accomplishes. Sometimes that’s a state change in a single object and sometimes that’s a collaboration between multiple objects. Sometimes a behavior will be technical, sometimes domain-specific or business oriented.

Features, on the other hand, are closer to stories. A feature (not always, but usually) will require a family of behaviors be present to work. And not all features are created equally. Users tend to think of features as larger workflows. These larger features, epics or I’ve taken to calling them narratives, are sometimes a little big for a small, tight iteration so I try to break them down to the smallest possible story that’s still readable, understandable, and able to be prioritized by an end user.

For me specifications describe behavior and behavior is a description of code: classes in an object system. It’s a happy side-effect that sometimes our domain model behaviors mean something to an end user, but an Account entity with a fully functional deposit method does not a feature make.

Where’s the value?

The flavor of BDD I’m talking about are class specifications. That’s to say that I had the best outcome by trying to derive value from BDD on a technical front. We take a story, provide enough acceptance criteria in the form of scenarios to estimate, and use those scenarios to create executable specifications that prove our code’s behavior.

It’s a little software value chain.

The value from this process is tremendous. First we get our refactoring safety net. By having a well specified codebase we can make changes with aplomb. We now have a nice regression suite and we get all of the quality benefits of unit testing and the design discipline of TDD.

What sets BDD (and specifically this class specification style of BDD) apart from TDD or unit testing is the fact that our specifications are now documentation. The create a localized codebase that can be entered by any developer: we’re closer to collective ownership. It does it in a way, however, where we can now start talking in a kind of mapping language. That mapping language involves both the ubiquitous language of the domain model(s) we have and the vocabulary around recipes a team will evolve for infrastructure (“oh, hey, use the Logger”).

It’s Not Over (Sorry)

This is a huge topic. I’m afraid I have more to say on the subject but in the interest of getting this out there I’m hitting the publish button. As a final sum-up, I’ll say that in my experience class specifications are the way to go.

Viewing BDD in this light has immediate benefits. I’m not throwing out the possibility that executable acceptance tests, “story runners,” or FIT-hybrids are a bad way to go, but I think they’re much more toward research and development. Class specifications done in a BDD style are the real deal. They work in the hear and now, so that’s where my enthusiasm and effort is directed.

I’ll unpack my theories about story runners in a future post. I’ll also talk a little bit about working vertically with BDD and this concept of Iteration I/O. We’re trying a few new things at my company that should provide some empirical basis for how we’re tackling questions around user documentation, acceptance testing, etc.
 

This entry was posted in Agile, BDD, collective ownership, opinion, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

19 Responses to Mapping BDD

  1. Colin Jack says:

    @David
    Ta for taking the time to reply, I definitely find this sort of thing and the discussion on the BDD forum useful in getting my head around what different people are doing.

    End-to-end or isolated. I agree but the lower level tests do have issues that bother me.

    Take any important method on a domain entity and look at the tests for it. Its highly likely they will tell you very little, at worst if you are really into mocking then all they show is that this entity contacts other entities/policies etc to do its work (not that I mock in domain testing other than testing services). To understand the behavior you have to dig and dig through the collaborators of the entity under test until you reach the specifications for the little unit that implements this behavior.

    Dunno, guess I’m a broken record on this topic :)

  2. Colin Jack says:

    “@Ian – I think Scott’s advice is good in: make no distinction. I’d call into question the need for functional tests as a necessary rigorous practice; when you’re be behaviors are well specified and those specifications prove true, and a feature relies on several system behaviors across several system layers or nodes and each of those layers or nodes contains the aforementioned specified code… well… I guess we’re trading rigor in the development workflow for a separate and hardcore tester-programmer role.”

    I’m not 100% sure I follow you here, looking at your Xeva tests and reading this entry…would you say to you BDD could be summed up as better TDD and that how/whether to handle old-school acceptance testing is out of scope?

    Oh and one thing that really interests me is whether BDD without the acceptance tests really what Dan North was envisioning?

    @Scott
    “I see that all tests are acceptance tests. Acceptance tests are indeed drivers from this perspective. I’m not just playing with semantics here. This is really one of those perspective changes that is typically accompanied by an audible click that emanates from somewhere deep in your psyche.”

    Aren’t you just using the term “acceptance test” here in a way that most people would not be familiar with. In my view most people would have the same view of acceptance testing as in the link Ian provided (http://www.extremeprogramming.org/rules/functionaltests.html).

    Whether they are truly end-to-end or sip the GUI is another matter, either way they are quite different from specifications/tests written against some low level implementation detail.

  3. Dave Laribee says:

    @Colin

    Great comments. Maybe I’ll take a stab at defining how _I_ use terminology in practice. I am happy with what I’m doing and it’s working out well, but it’d be good to get your level of critique. I’d appreciate it anyway.

    I’d also like to tackle the notion of end-to-end versus isolated testing. I think if you have excellent test coverage all the way through, specifications of a component’s behavior become part of the contract. Greg Young’s made mention that things like Spec# have the potential to change our spec/test burden. I think in a granular component-based system (such as an object system using a DI container), everything is a component and — as such — can be specified independently. Interfaces give us one piece of specification and those are irrefutable. Specs give us a more error-prone and subject to human skill piece of the contract pie. I’m rambling, so I’ll try and post something about this theory / do a little research / etc. soon.

  4. Colin Jack says:

    @Dave

    “Again, I’m thinking about this “metamodel ontology” thing you mentioned. I’m not creating that. The original BDD concept is weak around its language. Language is important. It’s key that we communicate in clear terminology and choose words for nuance and reject words that obfuscate. So here’s one little attempt to describe a facet.”

    In my view BDD does use language badly, and for all the talk of UL affecting BDD its clear that no two people practicing BDD (not that BDD is any one thing) use the same terms.

    Ultimately BDD is relatively simple so the language confusion seems to come from people misusing terms, inventing their own terms or using convoluted language that seems to make it all much more complex than it is (“metamodel ontology”).

    If we can keep it simple and explain exactly what we mean when we use overloaded terms (context/behavior/behavior/feature) then we’re a lot further forward.

    Not a specific comment on this posts use of language, just a comment on the general way BDD uses language.

    “Not 100% sure I understand this, but that’s never stopped me, so… Scenarios do link to stories. Scenarios help you drive out specifications. Sometimes contexts and specifications look exactly like scenarios. I’m a big believer in the importance of language and my sense of BDD sees me using five or six vocabulary words which I have no problem with. Consider the vocabulary around DDD, for example ;)”

    Sure but I have a cast in stone definition for the terminology in DDD but with BDD I still have no idea how one persons “scenario” relates to anothers. I can maybe piece together your meaning of each term from these blog entries and comments, but then I go to someone elses blog and I’m back at square one.

    Again not a comment specifically on this post, just on BDD in general.

  5. Dave Laribee says:

    @Ray & @Scott

    There’s always a larger “why” you can carry up the stack: release to product to portfolio to strategic levels. The higher you go and the larger you are and the more risk you have the more formal you probably need to get with this. This is, by-and-large, entering the realm of marketing that most of us developers only interact with in the form of product ownership or product management.

    Start-ups are, typically, high risk ventures. We’re all about building a platform that creates efficiencies (eliminates waste) in building business applications. We to bend our “so thats” around the concept of efficiency. Other reasons may be more political: “so that a key customer is satisfied.”

    Stories are no place for quant jocks, so I’d keep it lean. A quick calculation (assuming efficiency is your game) is: a) how many people does this story affect, b) what’s there ballpark hourly rate, and c) how many hours a month will this new feature save. Plug those numbers (or a range for each) and you can maybe start to get a rough idea of true business value. Of course, you can always measure that with a finer yardstick, but a loose gauge may be all you need.

    I’d caution that this probably shouldn’t be a developer exercise, though. Prioritizing is firmly in the hands of executive sponsorship, users, management. I’d also apply your math at a larger level such as an epic or a theme.

  6. Ray,

    The “why” questions should be answered in the user story in the “so that” part of the story. The “how” questions are answered in acceptance criteria and possibly a bit in the story, if the goal part of the story sheds any light on “how”.

  7. Dave Laribee says:

    @Colin

    > Are you saying that in OO terms a GUI prototype is-a user story acceptance criteria?

    Yes I am. We also have things like notes, technical constraints, and field lists as acceptance criteria. We keep it loose, but scenarios seem to have the biggest value in terms of creating clarity for closing a story and getting it right.

    > However you are linking them to user stories (as I do) so in that context are they not just individual acceptance criteria, does adding another term not confuse things or is there really a difference in the way you are using them?

    Not 100% sure I understand this, but that’s never stopped me, so… Scenarios do link to stories. Scenarios help you drive out specifications. Sometimes contexts and specifications look exactly like scenarios. I’m a big believer in the importance of language and my sense of BDD sees me using five or six vocabulary words which I have no problem with. Consider the vocabulary around DDD, for example 😉

    Awesome feedback! Thanks for taking the time!

  8. Dave Laribee says:

    @Ian – I think Scott’s advice is good in: make no distinction. I’d call into question the need for functional tests as a necessary rigorous practice; when you’re be behaviors are well specified and those specifications prove true, and a feature relies on several system behaviors across several system layers or nodes and each of those layers or nodes contains the aforementioned specified code… well… I guess we’re trading rigor in the development workflow for a separate and hardcore tester-programmer role.

    Not sure if I’m answering your question, and this is 100% my opinion, but it’s working in our little corner of the world 😉

  9. Dave Laribee says:

    @Peter – Yes I do. I see some of the big upsides of BDD as

    1) Being compatible with continuous delivery over BDUF.
    2) Coupling technical documentation to code and infusing ubiquitous language of the domain in that documentation thereby reducing the “geekiness” of the documentation and helping to close the gap between how and what, domain and technology, etc.
    3) A total replacement for code comments (99% of the time)
    4) A way to circulate in new team members and reduce code fiefdoms and code ownership.

  10. Dave Laribee says:

    @Scott – Metamodel? No. Metaphor! Also a desire to talk about behaviors in terms of artifacts. In a well-designed object system your contexts will drive out from your objects, as we (maybe?) agreed on the BDD list.

    In “writing” specifications I do see a behavior as a primary thing. I could be accused of trying to formalize that concept, as it sticks well with my installation BDD of a kind of class specification. I’ll stand by it. I find the term behavior off-putting when used with our customer team. Feature is something they understand. A behavior may sometimes be a feature, but that’s another story (no pun intended).

    Again, I’m thinking about this “metamodel ontology” thing you mentioned. I’m not creating that. The original BDD concept is weak around its language. Language is important. It’s key that we communicate in clear terminology and choose words for nuance and reject words that obfuscate. So here’s one little attempt to describe a facet. I think it’s also important that one remains flexible as this is an area where there’s innovation happening. I’m saying that more as a reminder to myself than anyone…

  11. Dave Laribee says:

    @Ray – specifications more capture the “what” from the outside. The inside of the specification may or may not capture the how. This goes back to the technique you’re using: e.g. mocks or stubs / state. Maybe I’m not understanding our question, but I’m not sure business folk generally do care about the “how.” Can you clarify?

  12. Ray Houston says:

    @David – I understand that the specs state “how” the system works, but what about the “why”? Where do you capture the ultimate business value of the “how”?

  13. Ian,

    I see that all tests are acceptance tests. Acceptance tests are indeed drivers from this perspective. I’m not just playing with semantics here. This is really one of those perspective changes that is typically accompanied by an audible click that emanates from somewhere deep in your psyche.

  14. > What exactly is a behavior? Is a behavior a feature? I vote no. I like to think of a
    > behavior as the smallest possible expression of one (and only one) thing that
    > a code artifact accomplishes.

    That’s not how I see behavior. I think of behavior as the “do” things. I can specify and observe behavior at a user task flow level: transfer funds between two accounts. And I can specify and observe behavior at a domain object level: transfer funds between two accounts.

    I agree with you that “behavior” and “feature” aren’t the same, but I can describe a feature in terms of its behavior: transfer funds between two accounts.

    I don’t really groove with the drive to create this metamodel ontology on top of BDD. It’s really much simpler than that.

  15. Nick Parker says:

    Good stuff Dave, I like the idea of describing the transitional flow as a software value chain. Nice Yoda reference too.

  16. Do you feel that BDD is “Agilizing” artifacts from a more “classic” development methodologies, artifacts that are prone to living in documentation that tends not to be a focus on agile projects?

    e.g. acceptance criteria is generally a pre-development specification (functional, system, software, etc.) artifact. Do you find that the focus on inter-personal communication over documents has lead to artifacts like acceptance criteria not being acceptably captured in Agile projects?

  17. Colin Jack says:

    @Ian
    Yeah this confused me a lot too when I was looking at BDD.

    Some people don’t actually rate the story based approach and instead focus on the combination of context/specification (better TDD IMHO). That is great, and well worth discussion and practice, but it isn’t really a massive advancement from TDD (its just a tweaked form of TDD in my view).

    Even when people do seem to use the approach that Dan North puts forward they don’t necessarily end up with acceptance tests in the style you describe. For example some people seem talk about making the story tests mocking tests (so acting as design aid) so in reality they aren’t acceptance tests. That’s fine though, but its just one example of how confusing the whole topic is.

    Anyway you might want to follow the BDD group, at the very least the discussions on there show how little agreement there is:

    http://groups.google.com/group/behaviordrivendevelopment/topics?gvc=2

  18. Ian Cooper says:

    @David

    Thanks definitely useful for those of us still trying to uncover what the BDD message is.

    My question would be this though. Agile teams have always identified acceptance tests as an iteration deliverable. When we break a story down into tasks, some of those tasks are acceptance tests. Defining the acceptance tests with the user is part of the iteration and further helps elucidate both the functional and non-functional requirements of the story. Some teams have generalists do this, others push the role out to SDTs. We are not prescriptive about how those tasks are achieved (xUNit, FIT, WatiR) as long as they are automated. Delivery includes these acceptance tests, passing, at the end of the iteration. use the appropriate tool.

    http://www.extremeprogramming.org/rules/functionaltests.html

    What I am missing is whether BDD is bringing some change in perspective here, or just putting all this into a package. For example my understanding was that BDD was pushing acceptance test first i.e. outside in and that in the same way that TDD says ‘write tests flrst’ BDD was saying ‘write acceptance tests first’. This would differ from the established agile approach in that methodologies like XP are not prescriptive about when the acceptance is written.

    But I’m not really sure if this is right?

  19. Colin Jack says:

    > Think of story structure, in this light, as an aggregate root. One story has zero-or-more
    > acceptance criteria. Acceptance criteria come in many flavors. Falling back on the object
    > oriented metaphor we can say that a specialization (or subclass) of a criterion is a
    > “User Interface Prototype.” We can define another specialization as the “Scenario.”

    Good article, just got a few comments.

    Are you saying that in OO terms a GUI prototype is-a user story acceptance criteria?

    I’d also assumed that the term “scenario” in the original BDD documentation was down to the fact that some of the thinking was linked to use cases (and thus usage scenarios). However you are linking them to user stories (as I do) so in that context are they not just individual acceptance criteria, does adding another term not confuse things or is there really a difference in the way you are using them?

    I can also see that making analogies between BDD and things that developers already do when developing seems like a good approach e.g. mapping/defining aggregates/sub classing/GUI prototypes. However in reality I’m not really sure it works as well as the bit where you just described how you actually used BDD.

    I’m only making these comments because when I started reading about BDD I found the content on the Web quite confusing. Everyone had different terminologies and understandings of BDD so trying to make sense of each article before trying to tie them together was a nightmare.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>