So, this post is a step by step how-to, from writing the Acceptance Tests with Specflow, then implement the Specflow steps, write Unit Tests, Write Code, Refactor.

So this means Red, Green, Red, Red, Green, Refactor

Lets create a Specflow Feature called Caluculator_Add.feature for our Add function of our Calculator.




With that example, we are happy because the default sample is going the same way. But let it make easier, i do not have much time today 🙂

This should usually write the Product Owner, Customer or Requirements Engineer. But it could also be another guy that works intensively with the previous Roles.

This is the content of my feature file:

The Feature describes what the feature is about and the scenarios are some parts of that story, some different tests what should be done that the PO accepts this.

-> If you run this feature now, its Inconclusive, because we did not defined the steps.

So lets create a folder called steps to put a class called CalculatorAddSteps where we will implement just the skeleton of that method.

This will usually do a developer, but probably not the developer who is implementing the story. But it could be a good way to do pair programming, one is doing the Specflow code, the other the unit tests and code.

-> If you run this feature now, its of course successful, because there is nothing to fail.

So lets implement the Step. (I assume that the Calculator Class and the Methods are created for that, because otherwise the project wont compile. But just as skeleton)


-> If you run this feature now, test is again failing, because we expect that the result is 120.

Now lets write the unit test for our Calculator class. We call the Class CalculatorTest. I know, this code is not pretty nice, but we must refactor it afterwards anyway.

-> If you run this unit test now, test is failing, because we expect that the result is 120 but is 0.

Lets implement now our Calculator class.


be aware, this is a very very easy and simple test. just to show you how to work with this tool.


-> Lets run now all tests 🙂 the feature and the unit tests. -> Its green. Now we should refactor it. But for our example it is not necessary.


But do not forget, you can speak with the guy who created the feature if you think this is not the right way how it should be tested. Rewrite it with that person. Its not always that you have a guy who knows how this should be written, so as a developer or the test developer, tell this guy. Communicate. Speak 🙂




Download the simple and easy solution from GitHub:



With this way of developing, we have a lot better quality of our code. The Acceptance Criteria is written in tests so everybody knows what we really have to do. We can use this as a documentation of our features and everybody is much happier than before. 😉

Specflow is just the tool for c#, but there are more for other languages such as Cucumber for Ruby on Rails.

enjoy and do ATDD (BDD)




ATDD with Specflow
Tagged on:         

Leave a Reply


Get every new post on this blog delivered to your Inbox.

Join other followers:

Welcome Damir Kusar

Log in

Lost your password?
%d bloggers like this: