Thursday, May 19, 2011

Subversion Setup for c# Developers

At work we use TFS for everything and I hate it. I like Subversion and find it very easy to use.

I often hear that Subversion doesn't integrate well with visual studio, and that it is hard to setup and run. Well both these assumptions are wrong.

If you are running any of the windows OSes all you have to do is install SvnServer, configure it, install TortoiseSVN so you can work with svn projects from window explorer. Finally in the extension manager in visual studio and install AnkhSvn or get it here. This will give you svn support in visual studio. below will be step by step with pictures.

Svn Server install
After downloading the msi, you will be presented with some config sections. There are two that really matter. The first pictured below will ask if you want the console along with the repositories. The second pictured below will be configuration for the repositories themselves.

once installed open the console and create your first user and group. I have a group for each project. Lets add our first user. Right click on the Users folder and click Create User. Fill out the dialog with username and password.

Lets add our first group. Right click on the Groups folder and select Create Group. A dialog will display. Fill in the name and add users to it. Once done click ok.

Then add a repository by right clicking on Repositories and Create new repository. Give it a name and check the create default structure.

Then add security to the repo by right clicking on the new project and selecting All Tasks => Manage Security. Change everyone to No Access, and add the group you created earlier with Read / Write.

Thats it for SvnServer.

Just install it and when in windows explorer you can right click on folders and there will be an added menu that allows you to do svn things, like checkout projects, update directories, commit changes and much more.

This is a plugin for visual studio 2010. To install it from visual studio go to extensions manager, click on online gallery => tools => source control and select AnkhSvn. It is free and it is awesome.

So after you create a new solution in visual studio, right click on the solution folder and select 'add solution to subversion'. Next fill in the repository url, and click ok. Thats it, it will now map your solution to your repository. Finally right click on the solution file and select, 'commit solution changes'. A dialog will open showing all modified files and gives you a chance to add a check in comment, do so and click ok. It will do it's thing and once done your project is now secure in your repository.

If you want to update your solution to the version in the repository just right click again on the solution file and select 'Update Solution to the Latest Version'. You can also select what version you want, revert local changes or anything else that is support by subversion.

Friday, May 06, 2011

BDD and Specflow

So recently I did a talk on BDD and showed off Specflow. Below are some of my notes from the talk, and I will try to find a place to host the code from the talk.


Technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally named in 2003 by Dan North[1] as a response to Test Driven Development, including Acceptance Test or Customer Test Driven Development practices.

BDD focuses on obtaining a clear understanding of desired software behaviour through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.

Some Jargon

A Stakeholder is a person who gets some value out of the system. Typical stakeholders are representative of groups of users, for example a trader or an administrator.
A Feature is a piece of system functionality that delivers value to one or more stakeholders. Executable specifications work best when described from the perspective of stakeholders, not technical infrastructure, since doing so enables business users to understand them better and engage more in discussions about what makes a particular feature complete.

Features are normally vertical functional slices of the system, for example transaction processing. Horizontal infrastructural slices, for example authorization, are not good as features. They do not deliver value directly to any stakeholders. Stakeholders will not be able to engage properly in specifying the acceptance criteria for such functionality, pretty much defeating the point of specification by example.

User Story
A User story is a rough description of scope for future work, used as a planning tool. Stories are vertical slices of system functionality that are deliverable independently. Each story should specify the value it brings to one or more stakeholders, the stakeholders that care about the story and the scope of the intended work. A common format for the stories is:
As a ..., I want..., So that... or In order to..., as a ..., I want ...

Stories often impact several features — a payment story might have an impact on transaction processing, fraud control and back-office reporting. Stories are often relatively small chunks of work to support frequent delivery. A single feature might be delivered through a large number of stories.

Good stories are not broad in scope and should be able to kick off a meaningful discussion.

What is SpecFlow (
A Tool to bind business readable behavior specifications to the underlying implementation. ie creates "Acceptance" test stubs for your features/User Stories, to help know when done is done at least for development.

Feature File
A Feature file describes a feature or a part of a feature with representative examples of expected outcomes. Specflow uses these files to validate some system functionality against its specifications. Feature files are plain-text files, ideally stored in the same version control system as the related project.

Each feature should be illustrated with Key Examples (Scenarios). The examples show the expected outcomes in specific representative cases with very precise information. This makes it absolutely clear what the system is expected to do and helps to avoid any misunderstanding and ambiguity. It also makes it possible for Specflow, to check whether the system works according to the specification.

A Scenario captures one key example for a feature in the feature file. It represents a way that the system delivers some value to a stakeholder. Scenarios are units of specifications for Specflow. Scenarios allow us to chop up feature functionality like Sushi, into chunks that can be separately consumed. Examples of good scenarios for credit card processing might be successful transaction authorization, transaction failure due to lack of funds, transaction failure due to wrong verification code and so on.

Steps are domain language phrases that we can combine to write scenarios. They can either refer to the context of a scenario, an action that the scenario describes or a way to validate the action.

What Makes a Good Feature File
The long term benefit of using Specflow comes from living documentation, a source of information on system functionality that is easily accessible to everyone and always current. To achieve that, a feature file should be:
  • Easy to understand
  • Consistent
  • Easy to access
To serve as a target for development that prevents misunderstanding and ambiguities, scenarios in a feature file should be:
  • Precise and testable
  • Specifications, not scripts
  • About business functionality not about software design.
Once a feature is implemented, the related file becomes a living document for the feature. To allow the software to evolve and provide functional regression checks, the scenarios should be:
  • Self explanatory
  • Focused
  • In domain language

Most importantly these files should be written collaboratively... BAs, Stakeholders, QAs, and Devs

So once the feature file is written Specflow will create some stubbed tests of the scenarios. the development team's responsibility is to fill in the stubs, and then make these tests pass. This does not mean that the developer wont need to write unit tests, since the tests created by Specflow are more broad in scope.

So once all the Specflow tests pass the developers know they have met the needs of the Stakeholder and can confidently check in their code.