With your SpecFlow installation comes SpecFlow.exe, a program that can be used to generate tests from the scenarios and create nicely formatted reports from the generated test results. There’s been a lot written about how to generate these reports when using NUnit (see this and this for example), but there’s been almost silence when it comes to managing this for MsTest. Facing this problem, I can see why… It’s a bit trickier.

In this blog post, I want to show you two things: how to generate MsTests from your .feature files and how to create a report from the generated results. Finally, I’ll show you how to put the two together and link it up to a nice “External tool” button in Visual Studio. Here we go:

Generate MsTests from your .feature file

With this step, you can generate the tests from your scenarios. SpecFlow.exe picks...

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 concept of tags has been 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. The über-cool @wip tag allows you to limit the number of items in progress for the team, perfect for Kanban lovers.

OK – but when I got around to trying it in SpecFlow, I was a bit disappointed to learn that only @ignore was supported… Or was it?

@ignore

@ignore is the only tag 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 to disable features and/or scenarios...

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 practicing agile methods.

Introduction

I’m currently working on a migration project with a fantastic team—possibly the best I’ve ever worked with. We’re converting a large VB6 application to VB.NET and WPF. Due to various reasons, we decided to do this in two phases:

1. Migrate everything with a tool and then get it to work again. Write an integration test that ensures the function works as expected.
2. Rewrite the underlying architecture bit by bit. Since we have integration tests in place, we are shielded from introducing any significant bugs.

In the first phase, we worked our way through the old code, form by form. There were 265 forms, and we created a simple tracking tool in Excel to classify each form as S, M, L, or XL (based on size in KB). As we progressed, we tracked the time spent...

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

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 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 (using the handy BeforeTestRun attribute of SpecFlow). But we have run into some issues…

This approach means we end up 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 came back to bite us.

The database name and backup name we’re restoring is stored in app.config, which means you need to change that on your local machine. A simple slip on check-in might have you distribute your app.config to the whole team, putting us...

Marcus Hammarberg embarks on an exploration of outside-in development with SpecFlow and ASP.NET MVC. In this narrative, he shares his journey from initial project setup to the implementation of specifications-driven code.

Setting the Stage

Excited about the opportunity to apply outside-in development practices to a real project, Marcus enters the office, ready to tackle the challenge. His project manager, Tobias, assigns him a task to extract tasks from the database to kickstart their learning journey.

Crafting Specifications

Together with Tobias, Marcus refines the project’s specifications, ensuring clarity and alignment with their goals. They define scenarios using Gherkin syntax to articulate the expected behavior of the application.

Implementation Begins

Marcus sets up his development environment in Visual Studio, configuring SpecFlow for executable specifications. He encounters initial challenges but perseveres, leveraging tools like Watin for browser automation to drive the development process forward.

Building the Web Application

With...