This is the second post talking about how to integrate the use of Team Foundation Server (TFS) in a Specification by example (BDD, ATDD call it what you want) workflow. You can read the first post here for some background, but I will include some background here too, as I have thought about it some more.

Background

Specification by example is not only a way to write executable specifications (red. those words still give me the chills) but in the way it’s used in projects lies some kind of agile methodology hidden. The early and frequent communication and documentation (in a commonly understood format, Gherkin) it fosters really get the way you work in a very agile way. More on that later. Cucumber is a very well known tool in the Ruby world, where projects often create web applications. I think that this inheritance has...

From time to time I find myself in the position where I ask “stupid” questions. I’ve found that it’s often the case that the question is not that “stupid” after all and if it is you get to learn a lot in the process. I have never been verbally abused, flamed or laughed at for my questions – which often are the reasons that people don’t want to ask “stupid” questions. So recently I’ve been asking “stupid” (final time I use that word in this post, promise) questions surrounding the management of features (.feature-files for us Cucumber freaks). And at the same time I’ve been searching high and low on the net for best practices on how to manage your features through the course of a project. I didn’t find much due to a couple of reasons:

• The Ruby/cucumber inheritance of .NET tools such as SpecFlow is great...

In my recent ventures into DOS-country and the SpecFlow.exe I noticed one last flag or subcommand that the SpecFlow.exe accepts; StepDefinitionReport. This subcommand will go through all your features and see which step definitions are called, how many times they are called and also if there is any step definitions that isn’t called at all. OK – that sounds real good, but for the life for me I couldn’t get it to work.

But since the source is open and available from gitHub.com I simply pulled a version down and tried to debug the code. And before long I found the solution. SpecFlow (now 2010-12-16) uses .NET framework 3.5, but my specifications were written using .NET 4.0. There are some reflection going on inside the step definition report code and that doesn’t work very well (loading assemblies from different framework versions).

OK – I simply change...

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 uber-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 discovered two fantastic frameworks that have significantly improved my test code: Should and NSubstitute.

Should I? Yes – You Should

First up is Should, an assertion framework that enhances the readability and ease of writing assertions. Here’s an example showcasing its capabilities:

object 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"

      Read More