I’ve just returned home from a course, marking my first training in over a year. It’s amazing how much you can learn in such a short time when the course and instructor are both excellent and you actively engage. This time, the course was led by Gojko Adzic, covering a subject I find both fascinating and valuable: Specification by Example.

Though it’s impossible to capture all the insights from two days of learning, I want to highlight the key takeaways and main points that stood out for me. As someone well-versed in BDD and Specification by Example, my goal was to gain practical tips on managing the early stages of specification, focusing more on the practicalities than the theoretical aspects.

Communicating with Examples

We began with a simulation of a Black Jack game to explore the pitfalls of traditional testing approaches. Our group fell into common traps:...

I got a question from Sham (Shamresh Khan) that I thought was interesting and also common. So I thought I post my answer here in the public and maybe we all can learn a bit.

Sham’s question was something like this:

…some of my scenarios/examples, may be very technical (i.e. checking some algorithm for example). If I write these tests under a user story (using the Gherkin syntax), a business analyst will be able to see them which may confuse them as they try to work out what scenarios exist under the user story or am I wrong here? Maybe all tests should be visible under a user story?

TDD and BDD

This is really one of the things we struggle with when coming from using TDD for a while and then starting doing BDD. In my opinion BDD is more than anything a communication tool that...

Last day was great. I didn’t go to anything that was really bad and I had some real highlights with Dan North, Gojko Adzic and Mark Rendle on Zen standing out as the best.

After a short and intense Lean Coffee I’m not sitting and waiting for the keynote with Jeff Atwood, who apparently just introduced himself and then went off the stage yesterday. Let’s see if he does the keynote himself today

Jeff Atwood on StackOverflow

Jeff did the talk himself (and talked fast, fast, fast!). He talked about how programmers need rules and likes to follow (or even create) rules. Take Facebook for example - who has a “list of their friends” at home. No-one! But a geek could understand social networks by creating rules around them. A list of friend for example.

Huh - I didn’t know that Jeff Atwood did invent the game-ification part of StackOverflow...

As always - after the first day my head was just spinning. I was so tired that I slept before I hit the pillow. But today I’m feeling great again and am ready for another great day of learning.

Dan North on Embracing uncertainty

Dan North is one of my true heroes in our industry. I’ve learned a lot of the stuff that I’m excited about from stuff he written and spoke about. This is about embracing uncertainty - which seems to sit nice with the whole BDD - Deliberate Discovery body of knowledge. Here’s a few things I jotted down:

Patterns of effective delivery (behavior patterns that is)

How we turned the agile manifesto upside down nowadays

The half-time of requirements - how long time before half the requirements needs to be rewritten

“We would rather be wrong than be uncertain!”

Christianity (!) and how faith become religion. Or values becoming rules...

I was very fortunate to go to OreDev this year. It’s just a great show - I described it as a “free bar of knowledge alcohol for learn-o-holics”. I thought I’ll take a few moments just to jot down some highlights and stuff I picked up during my first day at OreDev 2011. This is mostly for me… but you can read it if you want.

Jon Skeet on Async in .NET 4.0

I was late to the conference and missed the keynote, that I learned was awesome, and also late to this talk. Jon Skeet on the asynchronous features of .NET 4.0. I picked up some stuff though - most noteable I’ll check out the EduAsync blog posts and code that shows of all interesting features.

Aslam Kahn on Functional programming

From this great session I picked up how Alsam had learned functional programming...

SpecFlow.Assist.Dynamic came about from my own need when I wrote something that used Simple.Data.

I saw the power and simplicity (duh!) in Simple.Data by using dynamics. And I started to thinking on how it could be used in SpecFlow to further simplify and shorten up the code in my steps.

This is the third and final post on SpecFlow.Assist.Dynamic. Again this is not the formal documentation. It can be found here. These are just my personal preferences and thoughts on how to use it. This time with Simple.Data. And it won’t be long.

SpecFlow and Simple.Data

First you should check out Darren Cauthons post on using SpecFlow and simple data together. It shows the great use of a lightweight, simple data access framework in SpecFlow.

As I said in my earlier post test data management is something...

This is the second post about SpecFlow.Assist.Dynamic – a tool I wrote to help you write less code in your step definitions and focus on the actual steps instead of infrastructure. You can read the first post here – it explains what SpecFlow.Assist.Dynamic is.

In this post, I’ll show you some ways I use the dynamic features and some tricks that you might not know about.

Again – this is not the documentation for SpecFlow.Assist.Dynamic – that can be found here.

Installation

With the power of NuGet, it’s super-easy to install SpecFlow.Assist.Dynamic by simply running:

Install-Package SpecFlow.Assist.Dynamic 

(Sidenote: Ha! It’s good to try out your own stuff. I found a bug in version 0.2 on NuGet and fixed it with version 0.2.1.)

This command will also pull down the latest version of SpecFlow and other dependencies needed.

Test...

I’m excited to share a new NuGet package I’ve been working on: SpecFlow.Assist.Dynamic. This extension builds on SpecFlow and the fantastic Assist helpers created by Darren Cauthon.

In this post, I’ll cover what SpecFlow.Assist.Dynamic is, the problem it solves, and how it was developed. Future posts will delve into its usage and how it integrates with Simple.Data to enhance the testing experience.

The Problem

One of the common issues with SpecFlow is the need to create simple data transfer classes just to move data around in your step definitions. For example, consider the following Gherkin step:

Given the following users exist in the database: | Name | Age | Birth date | Length in meters | | Marcus | 39 |...