Tag Archives: BDD

Reflections of BDD Stories

Posted on by

There was an interesting discussion on the AgileSA Linked-in group around the use of BDD stories, and whether they should contain technical references or not.  I found myself saying that I don’t mind having, for example, a login story. To help Kevin Trethewey get over the shock and horror of this, I reflected on how my use of BDD stories has changed over time.

I remember Dan North explaining BDD stories to me when it was just a thought in his own mind.  That was around 2005 or 2006 and I remember being so inspired by the simplicity of the BDD grammar. So, seven or eight years later, let me share how my use has changed.  And, Kevin, I hope you enjoy your own journey too. It’s a lot of fun.

On CRUD.  I agree that CRUD is bad, blah, blah, blah.  But there are times when CRUD can a valid, and reasonable design choice. I don’t discount it, but it is not my first choice, and it is very rare for me. Oh, I sometimes just use it because I don’t know anything else about the domain. Once I discover more, I noticed that those CRUD things, quite naturally, fade away.

Who is the best judge of a story?  The customer is unlikely the best person to articulate these stories, nor judge the quality of the story. I have to guide them and extract that. I now ask the following questions.

  • Who are they?
  • What do they need?
  • What do they think they need?
  • What do they really want?

What does the story describe? Of the above questions, the last is the most powerful for me.  It balances my perspective. It stimulates creativity and moves me from the problem space to solution space. The story then exists in the solution space; i.e. it is now reflects a design intention, not a requirement statement in the problem space.

BDD stories are great conversation artifacts. It’s like a book on a coffee table. It stimulates conversation.  It is of same value as using a metaphor. In conversation with the customer, the story is mostly about things in the problem space. In other words, it is an analysis and clarifying tool. I found that direct, literal and very early use of this analysis statement as an executable specification results can result in brittle tests.

On the use of technical references. When I’m working in the design space and writing design stories, then I don’t mind if there is reference to a technical implementation such as a login screen.  At some time, I have to get concrete. I like getting concrete very early and abstract from that. It’s just how my mind works. So, if there is alternative authentication mechanism (say, LDAP or ActiveDirectory), then it is just another concrete implementation. If the authentication choice is an exclusive one, then, the abstraction of proprietary authentication and ActiveDirectory authentication doesn’t offer any benefit. So, I’ll just go for one of those and the story on task board will make reference to the technical aspects directly. It’s a great reminder of a design choice that is explicit to everyone.

Most stories start out as bad stories. My early stories in an unfamiliar domain are awful.  Like code, the story should exhibit single responsibility. That takes a lot of domain insight and discipline. Unfortunately, refactoring stories towards single responsibility is not trivial. It’s not as simple as extract class/method/variable. The result is that my story based test suite is in constant turmoil longer than it is calm with a few small ripples. For this reason, I use the story grammar as a conversation piece, but not as code artifact.

BDD Stories on the backlog. To avoid confusion about when the story is in the problem space or solution space, I don’t use BDD stories on the backlog. I prefer the XP style of a short phrase as a reminder of something to discuss.

On the use of outside-in style testing. I like outside-in to analyse the problem space, but I often find it equally valuable to evolve the design from the assertions inside-out.  I oscillate between the two perspectives rapidly and quite often. I think I’m searching for that harmony in perspective.  I then make it a choice to use the BDD story as an executable test for the outside in perspective. Often, though I find it unnecessary because I already have tests that reflect that perspective; it’s just not using the BDD grammar. Yet, the BDD grammar was a starting point. I just am not fixated on the BDD grammar being the ending point.

On the BDD grammar. From a language perspective, the BDD template is a general grammar that can be used to express any domain.  Just like we can use a general purpose language to solve any problem,  the BDD grammar can be used similarly. Yet, we have learned that domain specific languages can be more expressive of a particular domain.  Equivalently, I keep my mind wide open, looking for a story grammar that is domain specific.  For example, in a time sensitive domain such as investment portfolios, I might extract a grammar that expresses time as a first class citizen. There won’t be a “When” clause. I might have something like “At time t(0), the portfolio capital amount is…, at t(n) the portfolio has …, at t(n+1) the surrender value should be …”.

Remember, these are just reflections and observations about myself. Please don’t treat it as a gospel. You have your own journey that takes different pathways. Just enjoy those excursions.

Modeling out Loud

Posted on by

I will be running a 6 hour long session at the Scrum Gathering in Cape Town in September titled Modeling Out Loud.  I’m now convinced that the Scrum tribe are weird.  They call these sessions Deep Dives.  Presumably, you need to carry enough oxygen to survive the session.
I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories.  I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board.  So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.

Writing Specs is Writing Code is Designing

Posted on by

A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications.  They’ve also chosen cucumber as their acceptance testing tool.  All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle.  I think I’ve spotted the reason for this.
The feedback loop is missing.  They view the stories as a spec that has been handed down.  And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain.  It is a form of writing code.  But it’s just that this code is, maybe, non-executable.

Here’s my workflow and how I close the loop.

  • write story and scenario
  • Sketch a design if needed – helps when pairing to be on the same page.
  • Start writing test for scenario
  • ooops … test is getting complicated? stuck?
  • maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
  • or maybe the scenario was badly written? Ignore scenario structure, continue writing test.  Refactor scenario later.  We’re in deep discovery mode here.
  • get test to pass
  • refactor code
  • refactor scenario
  • … cycle the red-green-refactor until happy.

Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick.  Nothing is cast in concrete.  That’s why I like frequent feedback loops with tight turning circles.

No feedback loop, no progress.

BTW, I really don’t like explaining such things as flow-charts and sequences.  You got to find your own style.  It’s not a recipe or rules thing.  The above is something that is about as close to what I do but it changes when the need arises.  That’s also another key feature of being agile – adapt or die in the waterfall.

Correcting my Irresponsibility

Posted on by

I have received a lot of positive feedback from many new faces for the SPIN talk I did this week.  Thank you.
But I am worried.  In the 45 minute talk, I did 5 minutes with Ruby code and cucumber.  Now so many people want to use cucumber.  Good for cucumber.

I think I should have stressed my point a lot more.

Take-Home #1: Find a way to make the life cycle of requirements part of your workflow.  Should it be a hard dependency?  If the requirements change, then do you want the build to break?  When requirements have a life cycle independent of the code’s life cycle, then you are opening yourself to waterfall-ish problems.

Take-Home #2: Agile in name and process can only take you so far.  You have to live it in your head and in your life.  For me, agile has a very Zen-like characteristic.  You need to live in the moment, absorb the feedback in that moment and adjust your next action in response to all this stimuli.  We are just like an amoeba that reacts to changes in pH.  But the difference is that we are capable of controlling our re-action or subsequent action.  An amoeba is agile by process only.

Take-Home #3: BDD can help you to change your coding and architecture attitude for the better.  It is subtle in its intrusion, but profound in its impact.  The subtley makes it dangerous.  It is not about the clever use of words, it is about the way those words impacts on your code and your resulting architecture.  So find your own cucumber and that does not mean you should go looking for another gherkin.

Perhaps I was not responsible enough.  My actions and words have affected people in a way that I did not intend.

Enterprise Scrum and Killing the Stickman

Posted on by

At the 45th SPIN meeting in Cape Town tomorrow, I will be sharing the “stage” with Karen Greaves.  Karen will be talking about the lessons she has learned in rolling out Scrum to a large enterprise.  I have a feeling that it is about scaling Scrum out to more than 10 people.  Karen has done this for 80+ people and I am certain that her experiences will reach an audience outside of Scrum circles as well.
I will also be giving a talk about Agile Requirements.  It’s about behavior driven stories that go beyond traditional, fully dressed used cases.  However, I will focus a lot more about the process and thinking behind this approach as opposed to the code behind the stories.

I always meet very interesting people at SPIN.  Please take 2 hours from your evening and join us for some great geek chat at the Bandwidth Barnyard at 6.30pm on 15 April.

Update. You can get the presentation here.  The size is optimized for iPOD and is quite viewable on your desktop as well.  The tiny bit of ruby code is included in the zip as well.

Measuring the Clarity of Requirements

Posted on by

The last two geeky conversations I had, stumbled upon the same thing – how do you measure the effectiveness of requirements in describing the business to the business and describing the specification to the developer?
So, I posed the question “How far away are you from executing your requirements?”. If you are going to go through various steps and stages to get to compilation and then execution, then every step is an opportunity for valuable information being lost in translation. If you can compile your requirements immediately then nothing will be lost.

Each additional step between requirements description and compilation and execution is an opportunity to confuse the user and the developer and everyone in between.  That’s why fully dressed use cases are not so effective as fully dressed behavior driven stories.  And that’s why BDD is very agile and a great asset in DDD and use cases just don’t cut it anymore.

Right now, my favorite tool is Cucumber.  I can execute the requirements and that raises the clarity ranking of my requirements super high.

Heck! We should have paid attention that day.

Posted on by

I’ve been doing some internal DSL coaching recently, and my coaching-partner and I have been working BDD/TDD style.  It turned out to be quite a nice experience overall.  We started with a Cucumber based feature that described the behavior of a typical DSL script and we drove it down into rpsec where we tested each little part of the script.  In the end, I achieved what I set out: the person I was coaching grokked the whole “code is data” idea behind DSLs.
Then I started thinking about what it takes to coach external DSLs.  I got really scared – parsers, generators, abstract syntax trees.  Those were things that most people wanted to forget about the day after they wrote the exam for that horrible semester course in university.  What makes it worse is that I never did that in university – I did Electronic Engineering and we spent our coding time figuring out how to do Fast Fourier Transforms on digital signals.

But when I look at the progress that is being made in language workbenches to help us create DSLs, then I reckon we should dust off those books and start paying attention again.  Some of these language workbenches still leverage a host language such as Java or C#, but the act of using a structural editor that edits the AST directly is strangely weird.  But, some refactorings are just not a problem anymore.  For example, if you are changing the node on a tree, then all the references to that node are automatically aware of it.  Compare that to a text editor where you need refactoring wizardry in the tools to make sure all references are updated neatly.

I think that language workbenches may be a great tool for coaching DSLs because the things that made your head spin during that lex and yacc week, are made a whole lot simpler.  You can focus on designing the language and walk into ASTs with less fear.  But, be warned — language design is not easy, and you still need to know about ASTs and parsers and generators.  In fact, just write a parser and a generator and it will be a learning experience that goes beyond DSLs.  Better still, do it BDD/TDD style.

The relevancy of language oriented programming is just going to continually increase.  Those previously “irrelevant” courses are important again.  Watch out, the gap just got wider.

Øredev Presentations

Posted on by

My presentations from Oredev are finally available.  After working through almost all the export options on Keynote, I have settled on QuickTime as the distro format.  The “flying code” in the aspects presentation worked out best with QuickTime.  Note that it’s not a continuous playback and you have to click-through each frame.

Introduction to BDD

Posted on by
I will be giving a short introduction to behavior driven development (BDD) at the XP forum on 13 August 2008.  As usual, I’m using the opportunity to subtly throw in some other practices such as coding for readability and designing good messages.  I will also touch on mocking in tests as well.

I’ve been having immense fun putting together some code examples for this talk and I hope to demo BDD using JUnit, JBehave, RSpec (using the rbehave story runner on JRuby to test Java) and JTestR (which looks like a really exciting little project).

Come along and enjoy the fun.  Details and registration is on the JCSE web site.

Update 1: The Source Code for BDD Presentation is now available.

Update 2: The presentation is now available for download here.  It’s a 5MB Quicktime movie file. It’s not a continuous play movie, so you need to click through to the next slide.

Behaviour Driven Development at Cape Town Geek Dinner

Posted on by

Earlier this year I got to hear about Behaviour Driven Development from Dan North at the Software Architecture Workshop in Arosa, Switzerland.  Since then, I’ve been using BDD to various degrees on various projects, and I have to say that it works for me.A few nights ago, I presented BDD at the July GeekDinner in Cape Town. I had no idea how this approach will be received, but I was quite surprised by the interest and chatter that I had with others after the talk, especially around rbehave. I wonder how the conversation would have turned out had I used JBehave examples instead?The rest of the GeekDinner was, as always, an interesting mix of techie, geeky things. Jonathan Hitchcock has a nice wrap-up of the evening.Download my presentation here (PDF format).