Pickles Pro Blog .NET BDD from the trenches

A Pickles Task for FAKE

Pickles uses FAKE, a DSL for build tasks, to automate large parts of the build process. FAKE is really a quite accessible library for automating build scripts, and the fact that the build scripts are written in F# is rather charming (rather than a distraction).

FAKE naturally contains a lot of tasks, for example for copying files, compiling projects, creating NuGet packages. The other day I learned that FAKE also includes a task for Pickles! That’s right, you can generate your Living Documentation as a part of your FAKE build script!

The wonderful thing is that this happened without involvement from myself. This is the result of someone in the OSS community thinking “wouldn’t it be cool if Pickles and FAKE would work well together” and then going ahead and implementing it. This kind of recognition and contribution is one of the most sincere gifts that the community can make to an OSS project.

It totally made my day. It shows the strenght of a vibrant OSS community. Thank you!

Continue reading ...

Grocery Shopping with Software Developers

There’s a joke about a Software Developer who goes grocery shopping. It goes like this: suppose you send a Software Developer to buy groceries in the nearby store. You tell the Software Developer: “Buy a liter of milk. If they have eggs, buy six”. The store does have eggs, so what does the Software Developer buy? The answer to that question, the punch line of the joke, illustrates the need for Behaviour Driven Development.

Groceries

Continue reading ...

Quick Tip for the Automation Layer

Automation Layer code is just like any other piece of code. That means all the same rules apply to make it “good” code: SOLID Principles, refactoring, and good naming of variables to name just a few. Today’s post is about the latter: good naming of variables.

Continue reading ...

The Three Pillars of BDD

There are a lot of terms and aspects of Behaviour Driven Development (BDD) flying about, and it may not always be immediately obvious what the benefits of them are. I will attempt to bring some clarity here, and in doing so I will define the three pillars of BDD.

Three Pillars of BDD

Continue reading ...

Pickles 2.7 - Comments are optional

Earlier today, I released version 2.7 of Pickles. One of the features introduced in version 2.6 of Pickles in April was the inclusion of #-style comments in the living documentation. The reaction to that feature was mixed: people liked the ability to include #-style comments in principle, but some people would like to decide whether to include them for themselves.

Version 2.7 of Pickles now offers that ability, thanks to the work of William C. Smith. In the command line version of Pickles, you can use the enableComments argument to control inclusion of #-style comments. The default value is true, so if you do nothing, the #-style comments will be included as in version 2.6. See the documentation for the other runners.

Happy Pickling!

Continue reading ...

Example Mapping

As I’ve blogged about before, the collaboration between all roles in a project team is an essential part of BDD. It therefore stands to reason that we try to find ways to make this collaboration as engaging as possible. After all, if you have a planning meeting where all roles are present but most of the participants are zoned out, then you still won’t have a productive collaboration.

In December last year, Matt Wynne wrote a blog entry “Introducing Example Mapping” where he talks about a technique he has been using to make planning meetings both more interesting to attend and more effective in their outcome.

Continue reading ...

How To Name Your Scenario Outlines

Last week, I attended Gaspar Nagy’s Developing with SpecFlow course, and in this article I’m sharing one of my concrete learnings: how to name a scenario outline.

There are are a couple of schools of thought on how to name a scenario, but they all agree on this: the name of the scenario should reflect what the scenario is about, and should help you to grasp what business requirement was likely not met if the scenario fails.

For example, “Scenario 1” is not a good title, but “Suggest a long break after the 4th work block” is good.

This is all well and good for scenarios, but for a scenario outline things get more complicated.

Continue reading ...

Three Amigos or Three Musketeers?

The collaboration between all roles in a project team is an essential part of Behaviour Driven Development. There can be many roles in a team, but we usually assume three roles: business, development and test. It needs at least those three roles to make sure that the resulting specification

  1. will answer the business need,
  2. will be technically feasible, and
  3. will be adequately verified.

Representatives from these three (and potentially other) roles will meet to discuss requirements. They will work out a specification by coming up with examples.

Continue reading ...

Building Bridges - an Elevator Pitch for Behaviour Driven Development

It’s no secret that I’m setting myself up for a new career as a BDD coach. In preparation I’m taking part in a number of workshops, for example about marketing. During that workshop, I had to describe what a BDD coach does, what BDD is about.

Continue reading ...

Using Assertion Libraries

Code needs to be well-readable. After all, you will read a set of lines of code far more often than you write them. When it comes to expressing assertions in test code, the usual ways fall somewhat short of the mark. Assertion libraries can improve matters, and as a side effect reduce vendor lock-in.

Continue reading ...