Best Practices & Guidelines for BDD

Spread the love

Know About "Behavior Driven Development (BDD)"

Behavior Driven Development (BDD) is a strategy for creating programming through continuous example-based communication between developers, QAs and BAs. The basic role of BDD technique is to enhance communication among the stakeholders of the project with the goal that each component is effectively comprehended by all members of the team before development process begins. This helps to identify key scenarios for every story and furthermore to eradicate ambiguities from requirements.
BDDIn BDD, Examples are called Scenarios. Scenarios are organized around the Context-Action-Outcome pattern and are written in a special format called Gherkin. The scenarios are a method for explaining (in plain English) how a given element ought to act in various circumstances or with different input parameters. Since Gherkin is structural, it serves both as a specification and input into automated tests, thus the name "Executable Specifications".
Behavior Driven Development was developed by Dan North as a response to the issues like:
  • Where to start the process?
  • What to test and what not to test?
  • What to call the tests?
  • How to understand why a test fails?

Best Practices (Good Behavior)

Keep in mind, behavior situations are more than tests – they additionally speak to requirements and acceptance criteria. Great Gherkin originates from great behavior.

Phrasing Steps

Compose all steps in third-person perspective. On the off chance that first-person & third-person advances blend and situations wind up confusing, simply utilize third-person at all times.
Compose steps as a subject-predicate action phrase. It might entice to let parts of peech out of a step line for brevity, particularly when utilizing Ands and Buts, yet incomplete expressions make steps ambiguous and more likely to be reused improperly.
How about we consider a test that looks for pictures of pandas on Google. Underneath would be a sensible test method:
  • Open an web browser.
  • Navigate to
  • Enter "panda" in the search bar.
  • Click on the "Images" link at the top of the results page.
  • Images related to "panda" appears on the results page.

  • Feature: Google Searching
    Scenario: Google search result page elements
      Given the user navigates to the Google home page
      When the user entered "panda" at the search bar
      Then the results page shows links related to "panda"
      And image links for "panda"
      And video links for "panda"
    The last two "And" steps come up short regarding subject-predicate phrase format. Are the links meant to be subjects, implying that did they play out some meant? Or would they say they are meant to be direct objects, implying that they receive some action? Composing steps without a clear subject and predicate is not only poor English but poor communication.
    Additionally, utilize fitting tense for each sort of step. Givens ought to dependably utilize present or present perfect tense, Whens and Thens ought to dependably utilize present tense. The Given step above demonstrates an action when it says, "The user navigates." Actions always implies the exercises of behavior. Be that as it may, given steps are intended to build up an initial state, not exercise a behavior. Utilizing present or present perfect tense shows a state rather than an action.
    The correct example will look like this:
    Feature: Google Searching
    Scenario: Simple Google search
      Given a web browser is at the Google home page
      When the user enters "panda" into the search bar
      Then links related to "panda" are shown on the results page
    And keep on mind, all steps are written in third-person.

    Better Titles

    Good titles are considered as great steps. The title resembles the essence of a situation – it's the primary thing people read. It must convey in one compact line what the behavior is. Titles are regularly logged by the automation framework too.


    Another normal misguided judgment for amateurs is feeling that Gherkin has an "Or" step for conditional or combinatorial logic. People may assume that Gherkin has "Or" on the grounds that it has "And", or maybe programmers need to treat Gherkin like an structured language. Be that as it may, Gherkin does not have an "Or" step. Whenever automated, each step is executed consecutively.
    The following is a bad example based on ax classic Super Mario video game, showing how people might want to use “Or”:
    Feature: SNES Mario Controls
    Scenario: Mario jumps
      Given a level is started
      When the player pushes the "A" button
      Or the player pushes the "B" button
      Then Mario jumps straight up
    Clearly, the author’s wanted to present that Mario should jump when the player pushes either of the two buttons. The author intent to cover multiple variations of the same behavior. In order to do it on right terms, use Scenario Outline sections to cover multiple variations of the same behavior, as shown below:
    Feature: SNES Mario Controls
    Scenario Outline: Mario jumps
      Given a level is started
      When the player pushes the "" button
      Then Mario jumps straight up

    Examples: Buttons
    • | letter |
    • | A |
    • | B |

    Known Unknowns

    Test data can be hard to deal with. Some of the time, it might be possible to seed data in the system and compose tests to reference it, however in other time, it may not. Google search is the prime example: the data list or result list will change as both Google and the Internet change. To deal with the known unknown, compose situations protectively so changes in the underlying data do not cause test runs to fail. Besides, to be really behavior-driven, consider data not as test information but rather as examples of behavior.
    Consider the following example from the previous post:
    Feature: Google Searching
    Scenario: Simple Google search
      Given a web browser is on the Google page
      When the search phrase "panda" is entered
      Then results for "panda" are shown
      And the following related results are shown
      | related |
      | Panda Express |
      | giant panda |
      | panda videos |

    This situation utilizes a step table to unequivocally name results that appear to show up for a search. The step with the table would be executed to repeat over the table sections and check each showed up in the result list. Notwithstanding, imagine a scenario where Panda Express were to leave business and subsequently never again be positioned as high in the outcomes. (We strongly expect not.) The trial would then fail, not on the grounds that the search feature is broken, but rather in light of the fact that a hard-coded variation ended up invalid. It is smarter to compose a stage that all the more cleverly confirmed that each returned outcome by one way or another identified with the search query, like this way: "And links related to ‘panda’ are shown on the results page." The step definition execution could utilize standard articulation parsing to check the presence of "panda" in each result link.
    Another decent element of Gherkin is that step definitions can conceal information in the automation when it shouldn't be uncovered. Step definitions may likewise pass data to future steps in the automation. For example, consider another Google search scenario:
    Feature: Google Searching
    Scenario: Search result linking
      Given Google search results for "panda" are shown
      When the user clicks the first result link
      Then the page for the chosen result link is displayed

    Just take a notice how the When step does not explicitly name the value of the result link – in simple way it says to click on the first one. As the time passes by the value of the first link may change, but there will always be a first link. In order to successfully verify the outcome, the Then step must know something about the chosen link, but it can simply reference it as “the chosen result link”.

    Data Handling

    Some kind of test data should be handled directly within the ground of Gherkin, but other types must not. Keep on mind that BDD is specification by example – scenarios should be descriptive of the behaviors they cover, and any data composed into the Gherkin should support that descriptive nature.

    Less Is Better

    Scenarios should be short and sweet. It is frequently favored that scenarios should content a single-digit step count (<10). Long scenarios are complicated to understand, and they are often symbolic of poor practices. One such complication is writing imperative steps instead of declarative steps.
    Imperative steps define the mechanism of how an action should happen. They are highly procedure-driven. For example, consider the following When steps for entering a Google search:
    • When the user scrolls the mouse to the search bar
    • And the user clicks the search bar
    • And the user types the letter “p”
    • And the user types the letter “a”
    • And the user types the letter “n”
    • And the user types the letter “d”
    • And the user types the letter “a”
    • And the user types the ENTER key

    The granularity of actions may appear needlessly excess, yet it shows the point that imperative steps center particularly around how actions are taken. Along these lines, they regularly require numerous steps to completely achieve the intended behavior. Besides, the intended behavior is not always as self-documented as with declarative steps.
    Declarative steps imply what action ought to occur without giving the majority of the data to how it will occur. They are behavior-driven on the grounds that they express action at a higher level. The majority of the imperative steps in the example above could be written in one line: "When the user enters ‘panda’ at the search bar." The scrolling and key stroking is inferred, and it will at last be taken care of by the automation in the step definition. When attempting to reduce step count, inquire yourself as to whether your steps can be written more decoratively.
    Another explanation behind lengthy scenarios is scenario outline misuse. Scenario outline make it very simple to add pointless rows and columns to their Examples tables. Pointless rows squander test execution time. Additional columns indicate complexity. Both should be avoided. Below are questions to ask yourself when facing an over sized scenario outline:
    • Does each row represent an equivalence class of variations?
    • For example, searching for “elephant” in addition to “panda” does not add much test value.
    • Does every combination of inputs need to be covered?
    • N columns with M inputs each generates MN possible combinations.
    • Consider making each input appear only once, regardless of combination.
    • Do any columns represent separate behaviors?
    • This may be true if columns are never referenced together in the same step.
    • If so, consider splitting apart the scenario outline by column.
    • Does the feature file reader need to explicitly know all of the data?
    • Consider hiding some of the data in step definitions.
    • Some data may be derivable from other data.

    These questions are meant to be sanity checks, not hard-and-fast rules. The main point is that scenario outlines should focus on one behavior and use only the necessary variations.

    Structure and Style

    While style often takes a backseat during code review, it is a factor that differentiates good feature files from great feature files. In a truly behavior-driven team, non-technical stakeholders will rely upon feature files just as much as the engineers. Good writing style improves communication, and good communication skills are more than just resume fluff.
    Below are a number of titbits for good style and structure:
      1. Focus a feature on customer needs. 2. Limit one feature per feature file. This makes it easy to find features. 3. Limit the number of scenarios per feature. Nobody wants a thousand-line feature file. A good measure is a dozen scenarios per feature. 4. Limit the number of steps per scenario to less than ten. 5. Limit the character length of each step. Common limits are 80-120 characters. 6. Use proper spelling. 7. Use proper grammar. 8. Capitalize Gherkin keywords. 9. Capitalize the first word in titles. 10. Do not capitalize words in the step phrases unless they are proper nouns. 11. Do not use punctuation (specifically periods and commas) at the end of step phrases. 12. Use single spaces between words. 13. Indent the content beneath every section header. 14. Separate features and scenarios by two blank lines. 15. Separate examples tables by 1 blank line. 16. Do not separate steps within a scenario by blank lines. 17. Space table delimiter pipes (“|”) evenly. 18. Adopt a standard set of tag names. Avoid duplicates. 19. Write all tag names in lowercase, and use hyphens (“-“) to separate words. 20. Limit the length of tag names.

    Without these rules, you might end up with something like this:
    Feature: Google Searching
    @AUTOMATE @Automated @automation @Sprint32GoogleSearchFeature Scenario outline: GOOGLE STUFF
      Given a Web Browser is on the Google page, when The seach phrase "" Enter, Then "" shown. and The related results include "related".
    Examples: animals
      | phrase | related | | panda | Panda Express | | elephant | elephant Man |


      1- Clarify in the feature file what the feature is about, soon after the "Feature:" before continuing to the situations (preferably in “In order/As a/I want” format). 2- Write high-level scenario steps by raising the level of abstraction and spotlight on the "what" instead of the "how"
      • Don't make reference to UI components
      • Don't make reference to 'click' or different actions connected to explicit UI components
      • The scenario ought to stay legitimate if the UI is replaced with another UI tomorrow
      • Avoid extremely point by point steps where possible ((helps to focus and avoid clutter)

      Write scenarios using business language rather than using technical language so that it can be understood by everyone.
      3- Write down the scenarios from the point of view of the person who will utilize or needs the feature (not generally a member or user). Use 'I' and clarify who the 'I' is in 'Given' step. 4- Each and each scenario should be independent, i.e. scenarios ought not rely upon different scenarios or data created by different scenarios. 5- Don't make reference to features or actions which are not related to the actual feature under test.
      Example: Scenario is to check the balance is displayed currently in a user account. Before checking the balance, user needs to login to check the balance but Login is not part of the check balance scenario.6- Use Scenario Outline when you have many scenarios that pursue the very same pattern of steps, just with different input values or expected results. 7- Scenario Outline examples should be easy to understand. Column names should be meaningful (e.g. | Contact Method | Enquiry Type | instead of | value1 | value2 | ), so that the steps are understandable. 8- Scenarios need to be environment independent. 9- Write scenarios for testing happy paths and important error cases. 10- Avoid typos and always use grammatically correct English.


      1. Wherever possible steps should be reused. This can also be achieved by
      • parameterizing (if applicable)
      • keeping it short and simple
      2. Whenever a feature or behaviour changes the existing scenarios needs to be updated (from a latest branch in TFS) 3. Actions, which are not directly related to the scenario should be handled outside the actual scenario:
      • Actions like login should be handled part of Background or hooks.
      • Setup and teardown should be part of hooks and should not be part of the scenario.

    For more information about Behavior Driven Development Test Automation please drop an e-mail at -

    What OdiTek offers

    Refer our Skills page:

    Behavior Driven Development

    BDD (Behavior Driven Development) is a software development process that originally emerged from Test Driven Development (TDD). Behavior Driven Development is written in such a way that it illustrates the behaviour of the system, written in readable and understandable language for everyone involved in the...


    Client Testimonials

    We had a tough deadline to launch our .Net based application that processes a lot of data, and got very frustrated with our development agency we hired. Fortunately we got Oditek, and they took over seamlessly the product development, launched the app & continued feature development. Just awesome!

    Neal Bonrud

    Co-Founder – SubScreener, USA

    They were very attentive to our needs as clients and went out of the way to make sure our projects were taken care of. They were always able to get projects done in the specifications we requested. They are passionate about getting things done; I would definitely recommend them to lead any IT projects.

    Dann Manahan

    Sr VP Technology- 1031 Crowd Funding

    I worked with OdiTek on few high profile banking application projects. They did a fantastic job with web applications & manual testing on the VAS apps for two leading banks of UK that included rigorous UAT phases. I recommend them for any application development where security matters.

    Clive Shirley

    CTO- Smarta, UK

    OdiTek is our extended team who works on our key software projects. They are dependable, good in collaboration and technically very much to the level what we expect a global team should be. They had transformed our web applications, CRM and added mobility to existing business platforms here.

    Matt Berry

    IT Manager- First Option Online

    It's been more than 4 years now that we are working with OdiTek on our cloud based web product development. It's been amazing working together, they are very competent on designing scalable, high performance apps. Their technical support is outstanding to say the least, even at odd hours.

    Brad Taylor

    CEO- BluesummitTech, USA

    I am a fan of Team OdiTek since 2014 and have worked on many product development projects together. Specially worth mentioning their deliveries on VAS Banking web application development & manual testing services for Smarta, UK. They are highly skilled & a professional team to work with.

    Tom Bowden

    Digital Propositions - HSBC, London

    OdiTek has been working on our Integrated Web-scale Mobile Platform i.e. Optimal Health since 2014. They are very professional and takes care of the requirements meticulously. They are technically very sound and sincere in ensuring quality & performance. Wonderful working with them!

    Catherine Lim

    COO- Medilink Global Sdn Bdh

    You can trust the team, with minimum supervision you get the work done. They are honest, professional & committed to schedule & quality. I had been successfully running 3 business applications designed, developed and maintained by Oditek developers. It’s been a pleasure working with them.

    Scott Evans

    CEO- Pink Storage, UK

    OdiTek has been working in custom software development, including services for test automation. Many of them have worked with me in 2009-10 when I was R&D Manager in NetHawk India. They have great enthusiasm & a passion to excel in bringing customer success. Their work has been very impressive.

    Karen Hamber

    Senior Product Manager- Skype

    It's amazing to see these guys are turning their experience into a global delivery excellence at OdiTek. I am sure their past large scale product development experience will be handy to product companies. I would always recommend Oditek for software development, especially performance-driven solutions.

    Juha Marjeta

    Opti Automation Oyj

    If you need additional information or have project requirements, kindly drop an email to: