Every time I need to configure MsTest to work with SpecFlow I forget the syntax of it… Especially the first part…

The fact that it took me about 30 min to write this post is evidence enough that I should not spend any more on this. Here is my reference:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>
 <specFlow>
    <unitTestProvider name="MsTest" />
  </specFlow>
</configuration>

Also there is some additional config setting that you might want to tweak. Here is a complete version with default values:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>
 <specFlow>
    <trace traceSuccessfulSteps="true" traceTimings="false" minTracedDuration="0:0:0.1"/>
  </specFlow>
</configuration>

Since I first read about Cucumber in the excellent RSpec Book the concepts of tags has been the one that I haven’t really grasped. I liked the idea as outlined here, which states that you can use tags to organize your features and only run a subset of them. And the über-cool @wip-tag that allow you to limit the number of items in progress for the team. Yam for Kanban lovers. OK – but when I got around to try it in SpecFlow I was a bit disappointed to learn that the only @ignore was supported… Or was it?

@ignore

@ignore is in other words the only tag that is supported by default and is translated to “IGNORE” in your test framework of choice (for example Ignore in NUnit or MsTest). This can be used...

I have the good fortune to from time to time give courses in TDD. I organize these events in two parts; one theoretical background part and then a practical part. During the practical part I found great use of Code Katas in general and the Bowling Ball Kata in specific.

I really like the way that a kata helps you to focus on the thing you trying to learn and in the case of the bowling ball take you through the principles step-by-step.

However, lately I’ve also sheen that the very practice of gathering your team in a room and go through a coding exercise on a screen together, taking turns at the keyboard, has yet another great benefit. You start to talk about your code.

In this case you can together create a shared understanding, shared principles and code standard and finally build the team...

This is a well known truth for all doing agile method.

Introduction

I’m doing a migration project right now. My team is great - could be the best I’ve ever worked with. We’re converting a big VB6 application to VB.NET and WPF. And due to different reasons we decided to do this in two phases:

1. First migrate everything with a tool and then get it to work again. And write a integration test that assures that the function works as expected
2. Rewrite the underlying architecture bit by bit. Since we have integration tests in place we are shield from introducing any big bugs.

OK, the first phase mean that we worked our way through the old code, form by form. It was 265 of them and we created a simple tracking tool in Excel that classified each form as S, M, L or XL (based on...

Recently I’ve stumbled upon two great framework that greatly enhanced my test code.

Should I? Yes – you should

First up is Should – which is a assertion framework that makes your assertions much more readable and easier to write. Here’s some code that shows off it’s capabilities: object obj = null;

 obj = new object(); obj.Should().Be.OfType(typeof(object)); obj.Should().Equal(obj); obj.Should().Not.Be.Null(); obj.Should().Not.Be.SameAs(new object()); obj.Should().Not.Be.OfType<string>(); obj.Should().Not.Equal("foo"); "This String".Should().Contain("This"); "This String".Should().Not.Be.Empty(); "This String".Should().Not.Contain("foobar"); var list = new List<object>(); list.Should().Count.Zero(); list.Should().Not.Contain.Item(new object()); var item = new object(); list.Add(item); list.Should().Not.Be.Empty(); list.Should().Contain.Item(item); 

One really nice feature is that the framework isn’t tied to any testing framework but works nicely with any test framework.

Get me a substitute! Now

The other framework is NSubstitute which is a mocking framework. I first got hooked when I read their intro:

Mock, stub, fake, spy, test double? Strict...

I’m reading the excellent Switch: How to Change Things When Change Is Hard. And in it I stumbled on a interesting story, and when I started to think about how it could be applied in the Software development world I really got excited. But all in due time. Here is the story, in my shortened and simplified form (be sure to buy the book):

BP

The example is taken from a chapter (4) called Point to the destination that talks about good ways to show people where the goal is. Surrounding this example they are talking about sending a postcard from the future; Hey, look how warm and wonderful everything is here in the future when we have changed all that stuff…

Then the authors gives an example from BP (Yeah, I know that might sit bad with most people nowadays but forget the well in the...

In my last post I asked for comments, and it didn’t take Anders (Granåker) very long time to come up with a better and more correct solution to the problem.

The downside of my solution is that you need to tweak the build process on a build server for example. We knew that BUT I left it for later solving. There is a rename to be done and a moving of the real app.config etc.

OK - the solution has to do with the file-attribute on the AppSettings-node in .config-files. With that attribute you can point to another file that contains one or more keys from the appSettings-node. Two important things about that:

1. If the file is not present it will use the settings in the original app.config
2. If the file is present the settings in it will override any attributes that are specified in both places

Here...

[UPDATED] See this post for a different way to do this. In our current team we’re doing a lot of integration testing which means that we need a well known state in the database before each test run. We have solved this with a simple restore of a known backup before each test run (with the handy BeforeTestRun-attribute of SpecFlow). But we have run into some issues… That means that we destroying the database for each other all the time during development. So we created a small database for each developer and restored that before each test run. But again it jump back and bit us, I wont say where… The database name and backup name we’re restoring is stored in app.config which means that you need to change that on your local machine. A simple slip on check-in might have you distribute your app.config...

As part of my preparations for two different presentations on SpecFlow and BDD I found myself in need to create an example. And I have read loads of them (this is a great one by Steve Sandersson). I have also read some others that emphasized the outside-in style that I liked so much, but nothing in the .NET sphere. Finally I’ve tried the story telling approach to writing blog posts before and it was fun and well-received. So here is a story on outside-in development with SpecFlow and ASP.NET MVC. (Disclaimer – I will not go in to details on web automation or ASP.NET MVC).

Getting the story straight

Marcus entered the office with extra spring in his step. New project and he would finally get around to try out the outside-in development style in...

After working intensively with SpecFlow for a while now I have experienced something that I think is common. After a while you have all the steps you need… Or rather, if you write your step regular expressions carefully you’ll end up with a little language that automates the running of your application. So if you stay within the supported language you can simply write Gherkin. In Swedish for example.

It’s really cool to write Swedish that tells what the application should do. And it does it. I wrote about that experience before. The extension of this is that non-developers soon can start to write the specs and run them without any steps needed to be developed. But to do that you’ll need to have communicate which steps are supported.

Also after a while the supported regular expressions steps can be...