Tag Archives: BDD

Testing is just a laborious pain in the rear

Posted on by

I thoroughly enjoyed Karen Greave’s talk on Agile Testing.  She had just about 100% coverage (pun intended, groan).  Yet, testing is really a pain in the rear.  Testing is execution, and Karen was dead-on right, that automation is the path to follow.  Computers are very good at testing.  A computer does what it is programmed to do, and it can test the way it was programmed to test.  It’s simple: if testing is your constraint, move that constraint away from testing by automating.

Now, you have to deal with the constraint that shifted to the next point: test authoring.  While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise.  It is actually an exercise in confirming a shared, common understanding.  Kristin Nygard said “To program is to understand” and test authoring is a programming exercise.  That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language.  The act of authoring a scenario proves your understanding and the expected working of the software.

This is why I separate test execution (passive) from test authoring (active).  And Karen said that early feedback is good (right again), which is why I author my tests very early.  I’m extreme about this.  I test first.

Modeling out Loud Deep Dive

Posted on by

For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed.  It’s in no particular order, and it only makes sense if you attended the session.

  • BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
  • Because we understand something does not mean that we know how to design it.
  • Be aware of when you are analysing and when you are designing.
  • Be concrete and abstract late.
  • Use the scenarios to close the loop with product owners, stake holders, etc.
  • Developers should write BDD stories and scenarios.
  • We are less ignorant at the end of the sprint than at the beginning.
  • Use code to close the feedback loop for your story.
  • A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
  • Seek out the behavior and express intentions.
  • Use the value statement to explore alternative needs.
  • Product owners should not write BDD stories
  • Recycle stories if there are scenarios that you cannot commit to.
  • Keep out the technical jargon.  The moment you get technical, then the story shifts to an implementation.
  • Evolve and accept that it is ok to change … your story, your scenario, code, anything.
  • Login is not a story

There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.

The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.

And lastly, thanks for joining in.  I sincerely appreciate you making the time.

Remember that writing stories is a really difficult thing to learn, because is design is hard.  Persevere.

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).