BDD (Behavior Driven Development)
 

In the previous article we looked at how to do Test Driven Development (TDD) while doing the XP (Extreme Programming). In XP, the implementation of the tasks are done in the steering phase of the iteration planning. One of the tenets of the steering phase is “functional tests are run”. In this article we will see how to create functional tests using Behavior driven development (BDD) and its benefits.

Following are the some of the benefits of automated functional tests.

  • Functionality experienced by the User is tested
  • Saves testing time for the developers
  • Test in every environment (Dev, QA, Stage) without much effort
  • Generates confidence in every stake holder

Tools required for doing BDD in .Net

There are various tools available to do BDD in .Net. I have listed few of them below

SpecFlow is one of the most popular tools used in the .Net/C# community. And in this blog lets use the same. The tool comes as a Visual Studio Extension and can be downloaded directly from VS.

Creating a SpecFlow Project

Once SpecFlow extension is installed, the template required for doing BDD will be installed.

  • Create a simple “Class Library” Project in Visual studio
  • In the project, create a SpecFlow Feature file

Selecting the test framework

Before we Create/execute the scenario, we need to wire the SpecFlow with a compatible test framework. To do that we need to make changes to the app.Config file of the project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
  </configSections>
  <specFlow>
    <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
  <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
    <unitTestProvider name="xUnit" />
  </specFlow>
</configuration>

In this example we are using XUnit as the testing framework. SpecFlow supports a series of testing frameworks and more details can be found here.

Creating the Behavior

Now, let us look at how to create a functional test using behavior driven approach. Let’s consider the following story while creating a POS (point of sale) application for a super market.

“As a Supermarket POS app developer,  i would like the API to Give the total amount while billing so that I can wire up API against the UI.

Let’s write the Behavior required in order to implement the above API requirement .

Feature: SuperMarketProductsAPI
	As a Supermarket Biller 
	i would like the API to
	Give the total amount while billing
@SmokeTest
Scenario: Find the total amount while billing
	Given Shopping cart is filled with all the items required by consumer
	And Campaign information for the month is available in the system
	When I pass the cart to create bill API
	Then the total bill amount should be calculated

The above specification is written using the custom language (testing DSL) create by the specflow.org. (Please read about what is DSL here.)

There are 2 parts to the above Specflow specification

  • Feature – Denotes bigger context (description/story) of the application
  • Scenario – Specific workflow or behavior of the system under the feature. Each scenario has the following sub-parts
    • Given, And – describes what we already assumed available
    • When – The specific action which will trigger the workflow/behavior
    • Then  – expected behavior

 

Creating step definitions

When we run the unit test corresponding to the above test we it will fail as there are no definitions corresponding to the above scenarios.

Now Right Click on the feature file and select “Generate step Definitions”

You will see the pop-up like below, select “Generate” and then “Save” the file.

The file will have the details about “what SpecFlow should do when test is executed”.

using System;
using TechTalk.SpecFlow;

namespace SuperMarketFunctionalTests
{
    [Binding]
    public class SuperMarketProductsAPISteps
    {
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            ScenarioContext.Current.Pending();
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            ScenarioContext.Current.Pending();
        }
    }
}

When you build the project and execute the test corresponding to this, it will fail. This is because none of the parts of the test (given, when, then) are having implementation.

Writing code to make it work

Now that the behavior has been created, we are good to validate that with the team and implement the code/functionality corresponding to the requirement. Of course using best coding practices like TDD 🙂

Making the behavior test pass

In order to make the behavior test pass we need to write the implementation in the “Step Definition” file.

namespace SuperMarketFunctionalTests
{
    using Newtonsoft.Json;
    using System.Collections.Generic;
    using System.Net.Http;
    using TechTalk.SpecFlow;
    using Xunit;

    [Binding]
    public class SuperMarketProductsAPISteps
    {
        Product P1 = new Product { Name = "test1", Cost = 5 };
        Product P2 = new Product { Name = "test2", Cost = 10 };
        ShoppingCart cart;
        List<Campaign> campaign;
        Bill bill;
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            cart = new ShoppingCart { Products = new List<Product> { P1, P2 } };
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            campaign = new List<Campaign> { new Campaign { product = P1, discount = 1 } };
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            var client = new HttpClient();
            var response = client.PostAsync("http://myapi.supermarket.com", new StringContent(JsonConvert.SerializeObject(cart))).Result;
            var output = response.Content.ReadAsStringAsync().Result;
            bill = JsonConvert.DeserializeObject<Bill>(output);
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            Assert.True(bill.totalAmount == 14);
        }
    }
}

Once the code is there we can see the behavior test pass.

Conclusion

BDD is very powerful way of ensuring high code quality in conjunction with business requirement. In Extreme programming (XP) , BDD is considered to be a very important practice where functional tests are mandated to run at least once during the iteration.  Is BDD/Functional tests helping your team/business in achieving success or not ? Do let us know your thoughts.

Agile Capacity Planning (Download Template for free)
 

What is a Capacity Planning

The number of productive hours available for a sprint is called sprint capacity. The capacity is calculated before starting a sprint to identify how many stories team can accomplish for the upcoming sprint. This process is called capacity planning. This helps the team to make a commitment (How many story-points team would complete).

How to do Capacity Planning

You can download the template for capacity planning available at

Download AC Capacity Planning Template

Follow below steps

  1. Provide sprint start and end date. State daily total hours available each day for one person.
  2. Mention all the team member names (Column B11 onwards)
  3. Set high-level default percentages and click “Set Default Allocation” Button.
  4. The defaults will be set. These can be updated for individuals as per your team allocation.
  5.  Click “Plan Button”
  6. This would open capacity sheet with available hours for each individual for all days (Start to end of the sprint)
  7. You can make changes to individuals availability on specific days. Consider holidays, time off and other factors which affect hours for given days.
  8. Fill in details of past sprints if you have data. If not, you would start having that from next sprint onwards once you start using this planner.
  9. Based on past sprint data you get hours per story points in the Capacity sheet that would help us to derive how many story points we can really commit for upcoming sprint for which we are doing capacity planning.

Please note you can use the template I provided or any other template you or your company already have. My goal is just to make the process easy and make you understand the benefit.

Benefits

  • The availability percentage help us to identify available hours which eventually help us to pick the right amount of work for a given sprint.
  • Many sprint team does this manually which has two disadvantages
    • The chances of making mistake are high.
    • The velocity is either considered by averaging past few sprints or simply picking velocity of the previous sprint.  The better way is to multiply your capacity of a team with focus factor.

Focus Factor    =    (Average Velocity of previous sprints)/(Average  Capacity of previous sprints)

  • Improves focus and commitment which in turn increases chances of sprint success.
  • The holistic view of data that you get for past sprints using capacity planning does help in taking decisions and continuous improvement.

In order to see the real benefit of this template, you are expected to use the template for at least 3-4 sprints. Further, as you move, you see more benefits.

There are multiple teams I know leveraging this template I shared and I see them getting befitted out of it. This is the most basic template while if you think you want to add more to it, just provide the details in terms of what do you want and I will incorporate it into my template.

Question 1. How do I establish my capacity without historical data?

  1. Start with 8 story points (6 if the team is not very experienced) for each FTE. Let’s say there are 5 Developers and Testers (It would be 6*8 = 48). Do ensure to avoid adding points for Scrum Master or product owner.
  2. Subtract approx vacations from today (48 – Total vacation days)
  3. Find a story which would take less than a day and assign that to 1 story points
  4. You can estimate every other story relative to that. Do leverage Fibonacci series (1,2,3,5,8,13,20,40,80….) – Slight change for better results
  5. Don’t overdo it. Always remember that you start with something and get better.  A small effort is good enough. Lots of effort on estimation would not yield any results

Question 2. My team average velocity is 40 but now the whole team is moved to a newer sprint product team. Can I go with the same number? 

As I said, you can go with approx, to begin with, while if the product is completely new, reduce the number or better to use the same technique assuming there is no historical data.

 

Agile Abuse – Scenario 7 – We are agile hence lets update the story during run time
 

Neha – Developer 1, Bob – Product Owner, Peter – Agile Coach

Neha – We are always missing acceptance criteria and functional details in a story. It is really tough to commit a story with little or no clarity.

Bob – The Agile lets you evolve the requirements as you move. This is perfectly alright.  I am within the boundary. I will write the acceptance criteria when I get the time.

Peter- The requirements can evolve and that’s an advantage for a customer while stories cannot keep evolving during the sprint.  You have an opportunity to refine the acceptance criteria. If the functional requirements are not clear or acceptance criteria cannot be determined during planning/grooming, the story shouldn’t be committed. It should be moved for a later sprint.

Bob – Can I write the acceptance criteria and later change it altogether during the sprint as we progress?

Peter – No for sure. The change in a story once committed is a “scope creep”. You must move that to the next sprint of post-re-estimation, you might have to remove some other stories out of a sprint. Ideally, you are not allowed to change anything during a sprint. Adding more details to acceptance criteria to make it more clear as you move should be fine, though.

Bob – Fair! I will take out the stories where I don’t have clarity.

Challenge – Writing a one-liner description for a story should be fine and we will keep updating it while working in progress during the sprint. 

Scenario 1 – I leave very early because I finish my work and I pick very less because this is all I can do

Agile Abuse – Scenario 6 – Story point is not about time, not even a range
 

Sumant – Developer 1, Veena – Scrum Master

Veena – Sumant, we are almost at last day of sprint and your 3 pointers are not yet done. Do you see a risk? What is the tentative time you think you would take?

Sumant – I can’t tell you. Agile says that you cannot convert story points to time hence 3 pointers can take 3 days or 3 months. All valid in agile.

Veena – Why do you estimate your stories?

Sumant  – So that we know whether we can do that in our sprint or not.

Veena – And a sprint duration can be 3 months too?

Sumant – Oops, I got it.  My bad!

Challenge – The story point is not about time, not even a range.

 

Scenario 7 – We will unearth the acceptance criteria and requirements for a given story as we continue with development. Writing a one-liner description for a story should be fine and we will keep looking at it while working in progress during the sprint.

Agile Abuse – Scenario 5 – Let’s play with estimation whenever we want
 

Ron – Developer 1, Amy – Scrum Master

Amy – How come we committed 45 story points and we accomplished 51 though I have not added any extra work to sprint.

Ron – The performance improvement story was a little complicated hence I have added 6 additional points to it.

Amy – Once an estimate is done, it is not supposed to change in any case. If so, the whole point of estimation has no value.

Ron – Sorry, I will change that back to original and add the challenges encountered with that story to our process asset library.

Challenge – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range

Agile Abuse – Scenario 4 – Sprinting means running super fast
 

Paula – Customer, Amy – Manager

Paula – Amy, you mentioned that Agile is supposed to be faster. Why don’t you speed up the work with the same team? Sprint velocity is supposed to improve sprint after sprint and the speed of work should constantly increase.

Amy – Too much speed can affect the quality of work. Agile promotes sustainable development. In a long run, the overall benefit with respect to quality is going to be more compare to quantity in most circumstances while the sprint can run with a pace and all you can expect is better quality sprint after sprint.  100% utilization is an economic disaster.

Paula – OK. Got it.

Challenge – ‘Sprinting’ means running super-fast.

Scenario 5 – It is perfectly alright to play with estimation at any point in time.  

Agile Abuse – Scenario 3 – Converting standup to status meeting
 

Ron – Manager, Amy – Scrum Master

Ron – Amy, why the heck stand-ups are going for an hour every day.

Amy – The team prefers to talk and sort out open items. Although there is some unwanted discussions as well but that is just to keep morale up. It is truly helping us to sort out open items every day.

Ron – There is something wrong here. Are the questions being asked or clarification expected common to all?

Amy – Not really. Once in a while, it is general but typically it’s between two people.  It helps everyone to get the perspective.

Ron – You really need to take those discussions offline. The standup is supposed to end in less than 10 minutes (Worst case 15 minutes) for 10 member team.  You can do planning or grooming once or twice a week but that must have to be a separate meeting and not a standup.

Challenge – A standup cannot be a meeting.

Scenario 4 – ‘Sprinting’ means running super-fast.

Agile Abuse – Scenario 2 – Mixing Pairing and Knowledge Transition
 

Steve – Developer 1, Jeff – Developer 2

Steve (Evening) – Jeff, Can I pair with you on your story?

Jeff – Sure, but I am almost done with my story and moreover I would leave in another hour or so. If you are still interested, please join me.

Next-day – Morning standup

Steve – I worked on adding a comments field to our customer UI and further added that to the database.

Jeff – I paired with Steve. Status – Ditto!!!

Message – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Scenario 3 – A standup cannot be a meeting.