{"id":33,"date":"2019-06-17T10:06:10","date_gmt":"2019-06-17T10:06:10","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=33"},"modified":"2019-09-18T14:00:50","modified_gmt":"2019-09-18T14:00:50","slug":"how-to-write-bdd-scenarios","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/how-to-write-bdd-scenarios\/","title":{"rendered":"How to write BDD scenarios?"},"content":{"rendered":"\n

BDD stands for behaviour driven development<\/em>. TDD stands for test driven development<\/em>.<\/p>\n\n\n\n

Both BDD and TDD refer to the methods of software development employed by your engineering team. There are broadly 2 mainstream approaches to development: test driven development is one and behaviour driven development is the other.<\/p>\n\n\n\n

Test driven development<\/h3>\n\n\n\n

Test driven development is primarily concerned with the principle of unit testing. That is, testing specific, individual units of code.<\/p>\n\n\n\n

Your product\u2019s codebase is made up of small units of code which are responsible for specific parts of your application. Testing individual units of code is known as \u2018unit testing\u2019 and you may have heard your engineering team refer to unit tests.<\/p>\n\n\n\n

\"test<\/figure>\n\n\n\n

There are several stages and principles to be followed in test driven development. These stages and principles are summarised here:<\/p>\n\n\n\n

  1. All tests are written before<\/em> the code<\/li>
  2. Write a test<\/li>
  3. Run all tests to check that the new test fails<\/li>
  4. Write the code<\/li>
  5. Re-run the tests<\/li>
  6. Refactor the code if necessary<\/li>
  7. Re-run the tests<\/li><\/ol>\n\n\n\n

    The primary focus in test driven development is to ensure that the unit tests pass and that the \u2018build\u2019 is green. What\u2019s the build? Well, every time your engineering team add a new feature or story, they are adding it to \u2018the build\u2019. This works like adding a new frame to a movie. The build \u2013 the entire movie \u2013 is comprised of individual, specific frames and when a new frame is added, test are run to ensure the entire movie plays as it should.<\/p>\n\n\n\n

    If everything passes, this is typically known as the build being \u2018green\u2019. If the tests do not pass, the build is \u2018red\u2019 \u2013 something has broken and it needs to be fixed before your engineering team can proceed.<\/p>\n\n\n\n

    \"tdd<\/figure>\n\n\n\n

    The term \u2018code coverage\u2019 refers to the amount of your codebase which is covered by these types of tests. Your engineers, CTO and other technical leaders in your organisation will refer to code coverage targets as an aspirational target to achieve.<\/p>\n\n\n\n

    Benefits of TDD<\/strong><\/p>\n\n\n\n

    1. Short debugging time \/ effort<\/em><\/strong> \u2013 When a unit test fails, you\u2019ll know exactly what specifically has failed.<\/li>
    2. Safety net<\/em><\/strong> \u2013 tests become a safety net for the team \u2013 this can increase morale between engineers and bolster confidence in your engineering team.<\/li>
    3. Less bugs<\/em><\/strong> \u2013 more unit tests can often reduce the number of defects<\/li><\/ol>\n\n\n\n

      However, focusing exclusively on the code itself i.e. the technical aspects of a system, disregards the human, or behavioural<\/em>aspect of your application.<\/p>\n\n\n\n

      Behaviour driven development<\/h2>\n\n\n\n

      Behaviour driven development is different to test driven development. The 2 approaches are not necessarily mutually exclusive and are often used together.<\/p>\n\n\n\n

      The primary goal of behaviour driven development is to solve the problem of communication between the business (including the product manager), the engineering team and the machines.<\/p>\n\n\n\n

      \"behavior<\/figure>\n\n\n\n

      If you think about a recent feature that\u2019s been pushed to production, by the time a feature is deployed to production it will have moved through numerous stages, each with their own filters and interpretations. This set of chinese whispers is known as the cost of translation. The aim of behaviour driven development is to reduce the cost of translation<\/em>.<\/p>\n\n\n\n

      Broadly speaking, BDD is meant to eliminate many of the issues that TDD introduces. BDD tests use a more verbose language so that they can be read almost like you would read a sentence. The ability to read tests like a sentence is a cognitive shift in how you think about your tests.<\/p>\n\n\n\n

      The argument is that if your engineers can read their tests fluidly, they will write better and more comprehensive tests. It\u2019s often said that BDD is to help design the software, not test it and that TDD is meant to test it. Either way, BDD principles can help you and your team shift your mindset towards the behaviour of your product so that testing isn\u2019t from a purely technical perspective.<\/p>\n\n\n\n

      Principles of BDD<\/strong><\/p>\n\n\n\n

      1. BDD encourages simple languages to be used across teams, known as ubiquitous languages.<\/li>
      2. The simple and easy to use language should be used in the way the tests themselves are written, so that in theory, a business person can read a test and understand what it is testing.<\/li>
      3. Tests are often written from the customer\u2019s point of view; the focus is on the customers and the users who are interacting with the product<\/li><\/ol>\n\n\n\n

        Benefits of BDD<\/strong><\/p>\n\n\n\n

        1. Simple language<\/em><\/strong> \u2013 the straightforward language is usable\/understandable, not only by domain experts, but also by every member of the team.<\/li>
        2. Focus<\/em><\/strong> \u2013 BDD helps teams focus on a product\u2019s behavioral elements rather than focusing on testing the technical implementation in isolation through individual units. This subtle, but important shift, means that everyone is focused on what the behaviour of the product should be.<\/li>
        3. Using Scenarios<\/em><\/strong> \u2013 BDD is designed to speed up the development process. Everyone involved in development relies upon the same scenarios. Scenarios are requirements, acceptance criteria, test cases, and test scripts all in one; there is no need to write any other artifact.<\/li>
        4. Efficiency<\/em><\/strong> \u2013 BDD frameworks make it easy to turn scenarios into automated tests. The steps are already given by the scenarios \u2013 the automation engineer simply needs to write a method\/function to perform each step\u2019s operations.<\/li><\/ol>\n\n\n\n

          How to write BDD scenarios<\/h2>\n\n\n\n

          Your first question is probably \u2018what are BDD scenarios?\u2019. That\u2019s a fair question!<\/p>\n\n\n\n

          A BDD scenario is a written description of your product\u2019s behavior from one or more users\u2019 perspectives. Scenarios are designed to reduce the cost of translation and make it easier for your engineers to understand the requirements and for your QA (if you have one) to test it properly.<\/p>\n\n\n\n

          Using BDD scenarios means requirements and tests can be combined into 1 specification. In some cases, the scenarios that are written can then be easily converted into automated tests. BDD scenarios tend to follow a specific format. The format is fairly straight forward, and with a little practice you\u2019ll be able to write your own.<\/p>\n\n\n\n

          In order to explain how BDD and scenarios work in practice, let\u2019s take a look at the example of a user signing up to LinkedIn.<\/p>\n\n\n\n

          Example \u2013 signing up for a LinkedIn account<\/strong><\/p>\n\n\n\n

          \"signing<\/figure>\n\n\n\n

          Here\u2019s a basic BDD scenario which describes the LinkedIn signup process:<\/p>\n\n\n\n

          Scenario 1: User successfully creates a LinkedIn Account<\/strong><\/p>\n\n\n\n