Behavior driven development (bdd)

Editor's Notes

• #4: TDD is test centered development process in which we start writing tests firsts. Initially these tests fails but as we add more application code these tests pass. This helps us in many ways We write application code based on the tests. This gives a test first environment for development and the generated application code turns out to be bug free. With each iteration we write tests and as a result with each iteration we get an automated regression pack. This turns out to be very helpful because with every iteration we can be sure that earlier features are working. These tests serve as documentation  of application behavior and reference for future iterations.
• #5: BDD is popular and can be utilised for Unit level test cases and for UI level test cases. Tools like RSpec (for Ruby) or in .NET something like MSpec or SpecUnit is popular for Unit Testing following BDD approach.  Alternatively, you can write BDD-style specifications about UI interactions. Assuming you’re building a web application, you’ll probably use a browser automation library like WatiR/WatiN or Selenium, and script it either using one of the frameworks I just mentioned, or a given/when/then tool such as Cucumber (for Ruby) or SpecFlow (for .NET).
• #6: BDD Tools Cucumber & SpecFlow What is Cucumber? Cucumber is a testing framework which supports Behavior Driven Development (BDD). It lets us define application behavior in plain meaningful English text using a simple grammar defined by a language called Gherkin. Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python.   What is SpecFlow? SpecFlow is inspired by Cucumber framework in the Ruby on Rails world. Cucumber uses plain English in the Gherkin format to express user stories. Once the user stories and their expectations are written, the Cucumber gem is used to execute those stores. SpecFlow brings the same concept to the .NET world and allows the developer to express the feature in plain English language. It also allows to write specification in human readable Gherkin format.
• #7: Let’s assume there is a requirement from a client for an E-Commerce website to increase the sales of the product with implementing some new features on the website. The only challenge of the development team is to convert the client idea in to something that actually delivers the benefits to client. The original idea is awesome. But the only challenge here is that the person who is developing the idea is not the same person who has this idea. If the person who has the idea happens to be a talented software developer, then we might be in luck: the idea could be turned into working software without ever needing to be explained to anyone else. Now the idea needs to be communicated and has to travel from Business Owners(Client) to the development teams or many other people. Most software projects involve teams of several people working collaboratively together, so high-quality communication is critical to their success. As you probably know, good communication isn’t just about eloquently describing your ideas to others; you also need to solicit feedback to ensure you’ve been understood correctly. This is why agile software teams have learned to work in small increments, using the software that’s built incrementally as the feedback that says to the stakeholders “Is this what you mean?” Above image is the example of what clients have in their mind and communicated to the team of developers and how developers understands it and work on it. With the help of Gherkin language cucumber helps facilitate the discovery and use of a ubiquitous language within the team. Tests written in cucumber directly interact with the development code, but the tests are written in a language that is quite easy to understand by the business stakeholders. Cucumber test removes many misunderstandings long before they create any ambiguities in to the code.
• #8: Now after a look on the above example code anybody can understand the working of the test and what it is intend to do. It gives an unexpected powerful impact by enabling people to visualize the system before it has been built. Any of the business user would read and understand the test and able to give you the feedback that whether it reflects their understanding of what the system should do, and it can even leads to thinking of other scenarios that needs to be consider too.
• #9: Before diving in to Gherkin, it is necessary to understand the importance and need of a common language across different domains of project. By different domains I  By different domains I mean Clients, Developers, Testers, Business analysts and the Managerial team. Let’s start with talking about usual problems of a development project first and then we will move to a solution, while doing so we will come across the need for a common language. Assume you are a part of a technical team (Developer and Tester) and you have a task of collaborating with the business team (Business owners and Business analysts). You have to come up with the requirements of your project, these requirements will be what your development team will be implementing and test team will be testing. Also, that you have to make a small search feature on your E-Commerce platform. This feature will allow users to search for a product on your website. As we all might have faced in our experience that requirement given by business team are very crude and basic. For example, in this scenario we may get following requirements:   3.    Functional Requirements 3.1    Search Functionality 3.1.1     User should be able to search for a product 3.1.2    Only the products related to search string should be displayed.   Questions raised from the above requirements As we can see these requirements are good and useful but are not accurate. They describe a broad behavior of the system but do not specify concrete behavior of the system. Let me illustrate it by dissecting the first requirement, first requirement says that user should be able to search for a product but it fails to specify following – What is the maximum searchable length of search string? – What should be the search results if user searches for an invalid product? – What are the valid characters that can be used to search? *and similarly a few more detailed behavior of the application.   Usually in a project we end up asking above questions with the business team and we get replies, most of the replies reach the project documentation but the unfortunate ones are lost in emails and telephonic conversations. Also these replies are open to interpretation, for example: Question to Business Owner : What should be the search results if user searches for an invalid product? Reply from Business Owner : Invalid product searches should show following text on the search page: No product found   Answers of the Questions result in to more Doubts and Interpretation We get the answers of the questions asked from the Business team but it opens for interpretation or doubts in following ways: – Definition of invalid product is ambiguous and different team members will interpret it in different ways. One may consider that an invalid product is one which is not present in the inventory and other team member might consider an invalid product to be one which is a spelling mistake. – The answer by the business team says that “No product found” text should be displayed on the page. Does it says that a new search option should be present for the user? or may be related/similar search options should be displayed for the user? These are exact points where error is introduced in the system. Also, if we analyze the second doubt we would see that user Business team would love to have a new search option and related/similar searches option presented to the user. However, they were not able to think of this scenario when the question was asked. As a result what happened in the above example is Business team and the technical teams are communicating at two different levels, business team being vague and technical team trying to be precise. Ambiguity being introduced in the system, here by the definition of “invalid product”. Not enough insight being given to the Business team, so that they could have come up with new scenarios. Some details of project being lost in emails and telephonic conversations.   How to Improve the Requirement? Now let’s improve the first requirement given by the business team and try to make it more precise: “When a user searches, without spelling mistake, for a product name present in the inventory. All the products with similar name should be displayed“ “When a user searches, without spelling mistake, for a product name present in the inventory. Search results should be displayed with exact matches first and then similar matches“ Here we can see that how clear the requirements have become and with these clear requirements we are able to think more about the system. For eg. In the case of second requirement, after reading it we may think of other scenarios like: What should happen when there no exact and similar matches? Should the user be given an error message? Or the user is given a message stating when the product is expected to arrive in inventory.   What have we achieved here? We have forced the client to think in terms of details. With this improved thinking Business teams are coming with more refined requirements. This in turn with reduces the ambiguity in the project and will make developers and testers life easy by reducing the number of incorrect implementations. Also, you can see that each requirement now documents one exact behavior of the application. This means that it can be considered as a requirement document in itself.
• #11: We have forced the client to think in terms of details. With this improved thinking Business teams are coming with more refined requirements. This in turn with reduces the ambiguity in the project and will make developers and testers life easy by reducing the number of incorrect implementations. Also, you can see that each requirement now documents one exact behavior of the application. This means that it can be considered as a requirement document in itself.
• #12: To answer these problems Gherkin was created. Gherkin is a simple, lightweight and structured language which uses regular spoken language to describe requirements and scenarios. By regular spoken language we mean English, French and around 30 more languages.
• #15: Understanding of BDD Understanding SpecFlow, Cucumber Why BDD http://toolsqa.com/cucumber/behavior-driven-development/ Understanding Gherkin http://toolsqa.com/cucumber/gherkin/ Understanding of Feature File http://toolsqa.com/specflow/feature-file/ Understanding of Step Definition http://toolsqa.com/specflow/step-definition-file