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

In this blog post I want to show you two things; how to generate MsTest’s 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 MsTest’s from your .feature-file

With this step you can generate the test from you...

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 <a href=”https://github.com/aslakhellesoy/cucumber/wiki”target=”_blank”>Cucumber</a> 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...

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

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

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