There’s been a lot of buzz around Specification by example lately. At least in my networks and close to me. I hear it almost everyday at the office. A couple of days ago I was asked to do an introduction to the subject to a group of interested people. Striking also is that most people I hear talking about it is not developers (anymore) but rather business/requirements people and testers.

One question that I often get asked and that puzzles me is:

But who writes the specifications? Business people, developers or testers?

Maybe not exactly like that but something close too that. Actually I think the underlying intent is something else and has to do with ownership…

I have also discussed the topic with a few of my Twitter contacts that are involved in a project using Specification by example. In this...

I got a question from 3 colleagues on what Twitter is and how we should use it. I don’t claim to be an expert but I use it quite a lot everyday. So here is my introduction to Twitter – with my own opinions on how to use it. There are other introductions, like this by Scott Hanselmann, of course – but since they asked I might as well put it up here.

What is it?

From Wikipedia we learn that:

Twitter is an online social networking and microblogging service that enables its users to send and read text-based posts of up to 140 characters, informally known as “tweets.”

So you send short messages (tweets) that is picked up by anyone who follows you. You can follow a number of people to subscribe to their updates....

Right away – this blog post is mostly for me. I have not been dabbling enough with the “dynamic” keyword to say that I know it. This is what and how I understand it now.

So, if you care to read this… please be gentle with your comments. I love to see them and learn that I was wrong – I’m most certainly am.

dynamic keyword

Since .NET 4.0 we have a new keyword – dynamic. If you read the MSDN documentation you’ll learn that:

The dynamic type enables the operations in which it occurs to bypass compile-time type checking. Instead, these operations are resolved at run time.

Ok, but what useful is that? I mean you could write this, you probably shouldn’t but you could:

I’m loving NuGet and it’s totally changed the way I look on brining in external dependencies to my projects. I’ve written about that before.

But sometimes you want to install several packages into a project. For example, when you install SpecFlow into a project you also have to install a test framework such as NUnit or MsTest. And maybe an assertion framework or a mocking framework.

But this package will contain your (or your company) preferences and maybe not be suitable to publish to NuGet.org for everyone to download.

In this post I’ll show you how to easily create a  local package where you can setup the dependencies you want. And how to use it in your solution.

Strategy

Our sneaky plan is to basically create a package that only has dependencies. No code. And then store it in...

I have started to use dark theme for Visual Studio. You know about the site where you can get great themes, right? http://studiostyl.es/. I’m using the Son of Obsidian theme right now, but do check out Coding Instinct Theme by my colleague Torkel .

However – one thing that really bugs me was that the mouse pointer when in text edit mode (as it is in the code editor) goes to dark grey in the standard theme for Windows 7 (and XP and Vista, I understand).

That was a very complicated sentence but basically – my mouse pointer cannot be seen in the code editor. Very annoying.

I found the solution deep in a discussion here. “for cursor, select a windows black mouse scheme in control panel.”. That means the following – I didn’t even know you could do this:

• Open Control...

I got a very well formulated email from Jose Samonte the other day. He asked me about some resources on BDD and where to start learning about it. As I think this is a great question and I’ve struggled and read a lot before I got a grip on BDD I thought I post my answer publicly.

Start here

It all started with a blog post by Dan North; Introducing BDD. It provides some context on where the ideas came from and is a good read. While you’re there you should read “What’s in a story” – that article is equally good and provides a great background and understanding.

Learn from others

Now that we know the background and history we should go on. Much of the early work (and current to be honest) of the BDD was done on...

A lot of people read and appreciated the last post on Specification by example and Theory of constraints, so I thought I do a follow up.

I often find that your closest people are your best critics, so I asked a few of my colleagues for feedback. Håkan Forss (@hakanforss) is one of them that I respect very much in matters like these. He, like me, read and loved the Goal and I know that Håkan has great knowledge about theory of constraints and applying that kind of thinking in the system development process or other kind of knowledge work.

So it came as no surprise that Håkan had a few, rightful, objections to my reasoning. He’s points made me think another lap and I thought that it could be interesting to present it here.

To be able...

Since the first time I heard about Specification by example (or BDD if you like) I have had this nagging feeling that it fits like a glove with Lean thinking and the theories surrounding those ideas, but I haven’t been able to figure out how or why. Today I had some time to think hard about that and I think I found a connection. The connection I saw was how theory of constraints can be applied with the use of Specification by example to the system development process itself. In this blog post I’ll try to explain what I mean by that.

Standing on the shoulders of giants

This blog post is merely formulating my thoughts on this, or laying the puzzle from a lot of different pieces that other people have supplied. There are even people who supplied the complete picture, so...

If you are a developer doing BDD, as me, you’ll soon run into the joys of UI automation. The BDD community to day seems to lean towards running your specifications/test end-to-end in order to capture the whole stack of the application as well as getting great regression tests.

But tests against the GUI can be brittle, that part of the application is the one that most often is changed, in my experience. So writing automated stuff (in essence programs) against a changing environment is not very pleasant as you might well know.

This is post is about using the Page Object pattern that can help you handle this brittleness as well as structuring your test code in a nice, maintainable way. That in turn will help us to place code in the right place – which I like. Some guidelines, if you like.

Inspiration

I have of...

The other day I got the opportunity to try to figure out some elaborative error handling with SpecFlow and had to check up the ScenarioContext a bit closer. It turns out that there are some stuff on it that can be useful from time to time. And that it was a FeatureContext object as well. This post looks a bit closer on these to guys and gives some tips on how you might want to use them in your code.

ScenarioContext

Most of us has at least seen the ScenarioContext from the the code that SpecFlow generates when a missing step definition is found:

[Binding] public class StepDefinitions { [Then(@"I don't have this step definition in place yet")] public void ThenIDonTHaveThisStepDefintionInPlaceYet() { ScenarioContext.Current.Pending(); } } 

But there are some other interesting stuff you can do with and get from that object. I’ve tried...