After my latest post-of-admitting-failures I got some really nice feedback from a lot of people. Apparently there are others out there who think that a failure is a great learning opportunity. OK – I will most certainly continue down that path.

I actually write these posts as I code along. It’s forward only mode in other words… Almost.

Comments

One of the nicest things that happened as a result from the last post was that Darren Cauthon gave me some insightful comments and patches to go with them. This “social coding” that is going on, on www.github.com (a.k.a. programmers Facebook) is really, really cool.

Darren has done a lot of stuff in and around the SpecFlow project, for example the SpecFlow Assist (table helpers) that is really great. So I value his opinions a lot. He gave me 4 points to think about...

In my exploration of new Microsoft technologies, I’ve encountered the concept of scaffolding, particularly through tools like MvcScaffolding. Scaffolding is a well-known feature in other frameworks, such as Ruby on Rails, where it provides a quick way to generate code templates.

However, my encounter with scaffolding made me reflect on my high regard for Test-Driven Development (TDD) and how it influences my coding practices. TDD has significantly transformed how I approach code development—ensuring that my code is always driven by tests and that I don’t write unnecessary code.

The challenge arises with scaffolded code: it’s generated by a tool, not manually written. Should I write tests for this generated code? Should these tests be written before or after the code is generated?

Definitions

According to Wikipedia, scaffolding is:

Scaffolding is a temporary structure used to support people and material in the construction or repair of...

I’ve been involved and coached a project with several teams during the last year. The project aims to convert a big (and important) core business system from VB6 to the .NET platform.

It’s quite a big project with about 25-40 members (depending on which phase it’s in) and so we have several different teams working in parallel during the whole project. But it’s not until lately we’ve created a board to show the status for the whole project. Mainly due to high load in other areas of work, I have to admit.

This post will be a long one. But with a lot of pictures so I hope you won’t be bored .

Project status board

In order to easily and effortlessly communicate the status of the complete project, we have created a board on the project level that captures the status for each team. This is our first...

Disclaimers and introduction

I am now the father of three kids. They are my number one priority. This project will come second. I’m doing the project for myself mostly, but I’m very humbled by the fact that several people already have shown interest in my undertakings.

Up to now I’ve also had time to look at the project half-an-hour at a time. With several hours of back-in-my-head thinking in between. That might be good.

I have no master plan. I will make mistakes as you sure will notice in this post… I do not intend to document just the result but also my sidesteps and mistakes. I am a firm believer that it’s through our mistakes that we learn the most.

OK – on with the show.

In the first part of this series I simply wrote the first specification. So it’s no time to, outside...

News

The other day I just realized how much has changed in the way we develop code nowadays. Well, it might just be me, but there have certainly been some major changes in the .NET development arena.

I don’t claim this to be in the right chronological order, but here are some major milestones for me:

• TDD – didn’t use just 2 years back
• BDD – finally get the requirements and tester into the agile loop and an opportunity to work outside in, which feels just right for me. My favorite tool right now is SpecFlow.
• LINQ – totally changed the way C# (VB.NET still sucks at LINQ if you ask me) looks.
• ASP.NET MVC – a web framework that makes sense and that you can test. I understand again.

And now the other day (the day of the...

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>