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:

1

2

3

4

5

6

7

8

Feature:Calculator_Add

Inorder toavoid silly mistakes

Asamath idiot

Iwant tobe told the sum of two numbers

Scenario:Add two numbers

GivenIhave entered50and70into the calculator

Thenthe result should be120

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.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

using TechTalk.SpecFlow;

using NUnit.Framework;

namespaceDemo_Specflow.test.Steps

{

[Binding]

publicclassCalculatorAddSteps

{

readonly Calculator calculator=newCalculator();

[Given(@"I have entered (.*) and (.*) into the calculator")]

publicvoidGivenIHaveEnteredAndIntoTheCalculator(intp0,intp1)

{

}

[Then(@"the result should be (.*)")]

publicvoidThenTheResultShouldBe(intp0)

{

}

}

}

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

using TechTalk.SpecFlow;

using NUnit.Framework;

namespaceDemo_Specflow.test.Steps

{

[Binding]

publicclassCalculatorAddSteps

{

readonly Calculator calculator=newCalculator();

[Given(@"I have entered (.*) and (.*) into the calculator")]

publicvoidGivenIHaveEnteredAndIntoTheCalculator(intp0,intp1)

{

this.calculator.Add(p0,p1);

}

[Then(@"the result should be (.*)")]

publicvoidThenTheResultShouldBe(intp0)

{

intresult=this.calculator.Result;

Assert.AreEqual(p0,result);

}

}

}

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespaceDemo_Specflow.test.UnitTests

{

[TestClass]

publicclassCalculatorTest

{

privateCalculator calculator;

[TestInitialize]

publicvoidSetup()

{

calculator=newCalculator();

}

[TestMethod]

publicvoidAdd_50and70_120()

{

this.calculator.Add(50,70);

Assert.AreEqual(120,this.calculator.Result);

}

}

}

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

namespaceDemo_Specflow

{

publicclassCalculator

{

publicCalculator()

{

}

publicintResult{get;privateset;}

publicvoidAdd(inta,intb)

{

this.Result=a+b;

}

}

}

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 🙂

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.