Discuss Behavior Driven Development ”; Previous Next Behavior Driven Development (BDD) is a software development process that originally emerged from Test Driven Development (TDD). BDD uses examples to illustrate the behavior of the system that are written in a readable and understandable language for everyone involved in the development. Print Page Previous Next Advertisements ”;
BDD – Useful Resources ”; Previous Next The following resources contain additional information on Behavior Driven Development. Please use them to get more in-depth knowledge on this. Useful Video Courses A Practical Guide To SFDX and Salesforce CLI 38 Lectures 3 hours Manish Choudhari More Detail Test Driven Development in C++ Online Course 30 Lectures 2 hours Richard Wells More Detail Unit Testing and Test Driven Development in Python 31 Lectures 2 hours Richard Wells More Detail Unit Testing and Test Driven Development in NodeJS 33 Lectures 1.5 hours Richard Wells More Detail Build REST APIs with Django REST Framework and Python 68 Lectures 12.5 hours Packt Publishing More Detail Test Driven Development in .NET Core – The Handbook 27 Lectures 3.5 hours Packt Publishing More Detail Print Page Previous Next Advertisements ”;
Behavior Driven Development – Cucumber ”; Previous Next Cucumber is a tool that supports Executable specifications, Test automation, and Living documentation. Behavior Driven Development expands on Specification by Example. It also formalizes the Test-Driven Development best practices, in particular, the perspective of working from the outside-in. The development work is based on executable specifications. The key features of executable specifications are as follows − Executable Specifications are − Derived from examples, that represent the behaviors of the system. Written with collaboration of all involved in the development, including business and stakeholders. Based on acceptance criterion. Acceptance tests that are based on the executable specifications are automated. A shared, ubiquitous language is used to write the executable specifications and the automated tests such that − Domain specific terminology is used throughout the development. Everyone, including the customers and the stakeholders speak about the system, its requirements and its implementation, in the same way. The same terms are used to discuss the system present in the requirements, design documents, code, tests, etc. Anyone can read and understand a requirement and how to generate more requirements. Changes can be easily accommodated. Live documentation is maintained. Cucumber helps with this process since it ties together the executable specifications with the actual code of the system and the automated acceptance tests. The way it does this is actually designed to get the customers and developers working together. When an acceptance test passes, it means that the specification of the behavior of the system that it represents has been implemented correctly. Typical Cucumber Acceptance Test Consider the following example. Feature − Sign up Sign up should be quick and friendly. Scenario − Successful sign up New users should get a confirmation e-mail and be greeted personally. Given I have chosen to sign up. When I sign up with valid details. Then I should receive a confirmation email. And I should see a personalized greeting message. From this example, we can see that − Acceptance tests refer to Features. Features are explained by Scenarios. Scenarios consist of Steps. The specification is written in a natural language in a plain text file, but it is executable. Working of Cucumber Cucumber is a command line tool that processes text files containing the features looking for scenarios that can be executed against your system. Let us understand how Cucumber works. It makes use of a bunch of conventions about how the files are named and where they are located (the respective folders) to make it easy to get started. Cucumber lets you keep specifications, automated tests and documentation in the same place. Each scenario is a list of steps that describe the pre-conditions, actions, and post-conditions of the scenario; if each step executes without anyberror, the scenario is marked as passed. At the end of a run, Cucumber will report how many scenarios passed. If something fails, it provides information about what failed so that the developer can progress. In Cucumber, Features, Scenarios, and Steps are written in a Language called Gherkin. Gherkin is plain-text English (or one of 60+ other languages) with a structure. Gherkin is easy to learn and its structure allows you to write examples in a concise manner. Cucumber executes your files that contain executable specifications written in Gherkin. Cucumber needs Step Definitions to translate plain-text Gherkin Steps into actions that will interact with the system. When Cucumber executes a step in a scenario, it will look for a matching step definition to execute. A Step Definition is a small piece of code with a pattern attached to it. The pattern is used to link the Step Definition to all the matching steps, and the code is what Cucumber will execute when it sees a Gherkin step. Each step is accompanied by a Step Definition. Most steps will gather input and then delegate to a framework that is specific to your application domain in order to make calls on your framework. Cucumber supports over a dozen different software platforms. You can choose the Cucumber implementation that works for you. Every Cucumber implementation provides the same overall functionality and they also have their own installation procedure and platform-specific functionality. Mapping Steps and Step Definitions The key to Cucumber is the mapping between Steps and Step Definitions. Cucumber Implementations Given below are Cucumber implementations. Ruby/JRuby JRuby (using Cucumber-JVM) Java Groovy .NET (using SpecFlow) JavaScript JavaScript (using Cucumber-JVM and Rhino) Clojure Gosu Lua PHP (using Behat) Jython C++ Tcl Framework Integration Given below are Framework implementations. Ruby on Rails Selenium PicoContainer Spring Framework Watir Print Page Previous Next Advertisements ”;
Behavior Driven Development – Gherkin ”; Previous Next Gherkin is a language, which is used to write Features, Scenarios, and Steps. The purpose of Gherkin is to help us write concrete requirements. To understand what we mean by concrete requirements, consider the following example − Customers should be prevented from entering invalid credit card details. Versus If a customer enters a credit card number that is not exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits. The latter has no ambiguity and avoids errors and is much more testable. Gherkin is designed to create requirements that are more concrete. In Gherkin, the above example looks like − Feature Feedback when entering invalid credit card details Feature Definition In user testing, we have seen many people who make mistakes Documentation Background True for all Scenarios Below Given I have chosen an item to buy, And I am about to enter my credit card number Scenario − Credit card number too shortScenario Definition When I enter a card number that is less than 16 digits long And all the other details are correct And I submit the formSteps Then the form should be redisplayed And I should see a message advising me of the correct number of digits Gherkin Format and Syntax Gherkin files are plain text Files and have the extension .feature. Each line that is not blank has to start with a Gherkin keyword, followed by any text you like. The keywords are − Feature Scenario Given, When, Then, And, But (Steps) Background Scenario Outline Examples “”” (Doc Strings) | (Data Tables) @ (Tags) # (Comments) * Feature The Feature keyword is used to describe a software feature, and to group the related scenarios. A Feature has three basic elements − The keyword – Feature. The name of the feature, provided on the same line as the Feature keyword. An optional (but highly recommended) description that can span multiple lines i.e. all the text between the line containing the keyword Feature, and a line that starts with Scenario, Background, or Scenario Outline. In addition to a name and a description, Features contain a list of scenarios or scenario outlines, and an optional background. It is conventional to name a .feature file by taking the name of the Feature, converting it to lowercase and replacing the spaces with underlines. For example, feedback_when_entering_invalid_credit_card_details.feature In order to identify Features in your system, you can use what is known as a “feature injection template”. In order to <meet some goal> as a <type of user> I want <a feature> Descriptions Some parts of Gherkin documents do not have to start with a keyword. In the lines following a Feature, scenario, scenario outline or examples, you can write anything you like, as long as no line starts with a keyword. This is the way to include Descriptions. Scenario To express the behavior of your system, you attach one or more scenarios with each Feature. It is typical to see 5 to 20 scenarios per Feature to completely specify all the behaviors around that Feature. Scenarios follows the following pattern − Describe an initial context Describe an event Describe an expected outcome We start with a context, describe an action, and check the outcome. This is done with steps. Gherkin provides three keywords to describe each of the contexts, actions, and outcomes as steps. Given − Establish context When − Perform action Then − Check outcome These keywords provide readability of the scenario. Example Scenario − Withdraw money from account. Given I have $100 in my account. When I request $20. Then $20 should be dispensed. If there are multiple Given or When steps underneath each other, you can use And or But. They allow you to specify scenarios in detail. Example Scenario − Attempt withdrawal using stolen card. Given I have $100 in my account. But my card is invalid. When I request $50. Then my card should not be returned. And I should be told to contact the bank. While creating scenarios, remember ‘each scenario must make sense and be able to be executed independently of any other scenario’’. This means − You cannot have the success condition of one scenario depend on the fact that some other scenario was executed before it. Each scenario creates its particular context, executes one thing, and tests the result. Such scenarios provide the following benefits − Tests will be simpler and easier to understand. You can run just a subset of your scenarios and you do not have to worry about the breaking of your test set. Depending on your system, you might be able to run the tests in parallel, reducing the amount of time taken to execute all of your tests. Scenario Outline If you have to write scenarios with several inputs or outputs, you might end up creating several scenarios that only differ by their values. The solution is to use scenario outline. To write a scenario outline, Variables in the scenario outline steps are marked up with < and >. The various values for the variables are given as examples in a table. Example Suppose you are writing a Feature for adding two numbers on a calculator. Feature − Add. Scenario Outline: Add two numbers. Given the input “<input>” When the calculator is run Then the output should be <output>” Examples | input | output | | 2+2 | 4 | | 98+1 | 99 | | 255+390 | 645 | A scenario outline section is always followed by one or more sections of examples, which are a container for a table. The table must have a header row corresponding to the variables in the scenario outline steps. Each of the rows below will create a new scenario, filling in the variable values Print Page Previous Next
Behavior Driven Development – Quick Guide ”; Previous Next Behavior Driven Development – Introduction Behavior Driven Development (BDD) is a software development process that originally emerged from Test Driven Development (TDD). According to Dan North, who is responsible for the evolution of BDD, “BDD is using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matter.” BDD uses examples to illustrate the behavior of the system that are written in a readable and understandable language for everyone involved in the development. These examples include − Converted into executable specifications. Used as the acceptance tests. BDD – Key features Behavior Driven Development focuses on − Providing a shared process and shared tools promoting communication to the software developers, business analysts and stakeholders to collaborate on software development, with the aim of delivering product with business value. What a system should do and not on how it should be implemented. Providing better readability and visibility. Verifying not only the working of the software but also that it meets the customer’s expectations. Origin of BDD The cost to fix a defect increases multifold if the defect is not detected at the right time and fixed as and when it is detected. Consider the following example. This shows that unless requirements are obtained correctly, it would be expensive to fix the defects resulting from misunderstanding the requirements at a later stage. Further, the end product may not meet the customer’s expectations. The need of the hour is a development approach that − Is based on the requirements. Focuses on requirements throughout the development. Ensures that the requirements are met. A development approach that can take care of the above-mentioned requirements is BDD. Thus, Behavior Driven Development − Derives examples of different expected behaviors of the system. Enables writing the examples in a language using the business domain terms to ensure easy understanding by everyone involved in the development including the customers. Gets the examples ratified with customer from time to time by means of conversations. Focuses on the customer requirements (examples) throughout the development. Uses examples as acceptance tests. BDD Practices The two main practices of BDD are − Specification by Example (SbE) Test Driven Development (TDD) Specification by Example Specification by Example (SbE) uses examples in conversations to illustrate the business rules and the behavior of the software to be built. Specification by Example enables the product owners, business analysts, testers and the developers to eliminate common misunderstandings about the business requirements. Test Driven Development Test Driven Development, in the context of BDD, turns examples into human readable, executable specifications. The developers use these specifications as a guide to implement increments of new functionality. This, results in a lean codebase and a suite of automated regression tests that keep the maintenance costs low throughout the lifetime of the software. Agile BDD In Agile software development, BDD method is used to come to a common understanding on the pending specifications. The following steps are executed in Agile BDD − The developers and the product owner collaboratively write pending specifications in a plain text editor. The product owner specifies the behaviors they expect from the system. The developers Fill the specifications with these behavior details. Ask questions based on their understanding of the system. The current system behaviors are considered to see if the new feature will break any of the existing features. Agile Manifesto and BDD The Agile Manifesto states the following − We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value − Individuals and interactions − over Processes and tools Working software − over Comprehensive documentation Customer collaboration − over Contract negotiation Responding to change − over Following a plan That is, while there is value in the items on the right, we value the items on the left more. BDD aligns itself to the Agile manifesto as follows − Agile Manifesto BDD Alignment Individuals and interactions over processes and tools. BDD is about having conversations. Working software over comprehensive documentation. BDD focuses on making it easy to create software that is of business value. Customer collaboration over contract negotiation. BDD focuses on scenarios based on ideas with continuous communication with the customer as the development progresses. It is not based on any promises. Responding to change over following a plan. BDD focuses on continuous communication and collaboration that facilitates absorption of changes. BDD – Test Driven Development When you look at any reference on Behavior Driven Development, you will find the usage of phrases such as “BDD is derived from TDD”, “BDD and TDD”. To know how BDD came into existence, why it is said to be derived from TDD and what is BDD and TDD, you have to have an understanding of TDD. Why Testing? To start, let us get into the fundamentals of testing. The purpose of testing is to ensure that the system that is built is working as expected. Consider the following example. Hence, by experience we have learnt that uncovering a defect as and when it is introduced and fixing it immediately would be cost effective. Therefore, there is a necessity of writing test cases at every stage of development and testing. This is what our traditional testing practices have taught us, which is often termed as Test-early. This testing approach is termed as the Test-Last approach as testing is done after the completion of a stage. Challenges with Test-Last Approach The Test-Last approach was followed for quite some time in the software development projects. However, in reality, with this approach, as testing has to wait till the particular stage is completed, often it is overlooked because of − The delays in the completion of the stage. Tight time schedules. Focus on delivery on time, skipping testing. Further, in the Test-Last approach, Unit testing, that is supposed to be done by the developers is often skipped. The various reasons found are
Behavior Driven Development – Introduction ”; Previous Next Behavior Driven Development (BDD) is a software development process that originally emerged from Test Driven Development (TDD). According to Dan North, who is responsible for the evolution of BDD, “BDD is using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matter.” BDD uses examples to illustrate the behavior of the system that are written in a readable and understandable language for everyone involved in the development. These examples include − Converted into executable specifications. Used as the acceptance tests. BDD – Key features Behavior Driven Development focuses on − Providing a shared process and shared tools promoting communication to the software developers, business analysts and stakeholders to collaborate on software development, with the aim of delivering product with business value. What a system should do and not on how it should be implemented. Providing better readability and visibility. Verifying not only the working of the software but also that it meets the customer’s expectations. Origin of BDD The cost to fix a defect increases multifold if the defect is not detected at the right time and fixed as and when it is detected. Consider the following example. This shows that unless requirements are obtained correctly, it would be expensive to fix the defects resulting from misunderstanding the requirements at a later stage. Further, the end product may not meet the customer’s expectations. The need of the hour is a development approach that − Is based on the requirements. Focuses on requirements throughout the development. Ensures that the requirements are met. A development approach that can take care of the above-mentioned requirements is BDD. Thus, Behavior Driven Development − Derives examples of different expected behaviors of the system. Enables writing the examples in a language using the business domain terms to ensure easy understanding by everyone involved in the development including the customers. Gets the examples ratified with customer from time to time by means of conversations. Focuses on the customer requirements (examples) throughout the development. Uses examples as acceptance tests. BDD Practices The two main practices of BDD are − Specification by Example (SbE) Test Driven Development (TDD) Specification by Example Specification by Example (SbE) uses examples in conversations to illustrate the business rules and the behavior of the software to be built. Specification by Example enables the product owners, business analysts, testers and the developers to eliminate common misunderstandings about the business requirements. Test Driven Development Test Driven Development, in the context of BDD, turns examples into human readable, executable specifications. The developers use these specifications as a guide to implement increments of new functionality. This, results in a lean codebase and a suite of automated regression tests that keep the maintenance costs low throughout the lifetime of the software. Agile BDD In Agile software development, BDD method is used to come to a common understanding on the pending specifications. The following steps are executed in Agile BDD − The developers and the product owner collaboratively write pending specifications in a plain text editor. The product owner specifies the behaviors they expect from the system. The developers Fill the specifications with these behavior details. Ask questions based on their understanding of the system. The current system behaviors are considered to see if the new feature will break any of the existing features. Agile Manifesto and BDD The Agile Manifesto states the following − We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value − Individuals and interactions − over Processes and tools Working software − over Comprehensive documentation Customer collaboration − over Contract negotiation Responding to change − over Following a plan That is, while there is value in the items on the right, we value the items on the left more. BDD aligns itself to the Agile manifesto as follows − Agile Manifesto BDD Alignment Individuals and interactions over processes and tools. BDD is about having conversations. Working software over comprehensive documentation. BDD focuses on making it easy to create software that is of business value. Customer collaboration over contract negotiation. BDD focuses on scenarios based on ideas with continuous communication with the customer as the development progresses. It is not based on any promises. Responding to change over following a plan. BDD focuses on continuous communication and collaboration that facilitates absorption of changes. Print Page Previous Next Advertisements ”;
Behavior Driven Development – SpecFlow ”; Previous Next SpecFlow is an open-source project. The source code is hosted on GitHub. The feature files used by SpecFlow to store an acceptance criterion for features (use cases, user stories) in your application are defined using the Gherkin syntax. The Gherkin format was introduced by Cucumber and is also used by other tools. The Gherkin language is maintained as a project on GitHub − https://github.com/cucumber/gherkin Feature Elements and SpecFlow The key features of Feature elements are − The feature element provides a header for the feature file. The feature element includes the name and a high-level description of the corresponding feature in your application. SpecFlow generates a unit test class for the feature element, with the class name derived from the name of the feature. SpecFlow generates executable unit tests from the scenarios that represent acceptance criteria. A feature file may contain multiple scenarios used to describe the feature”s acceptance tests. Scenarios have a name and can consist of multiple scenario steps. SpecFlow generates a unit test method for each scenario, with the method name derived from the name of the scenario. Multiple Scenario Steps The scenarios can have multiple scenario steps. There are three types of steps that define the preconditions, actions or verification steps, which make up the acceptance test. The different types of steps begin with either the Given, When or Then keywords respectively and subsequent steps of the same type can be linked using the And and But keywords. The Gherkin syntax allows any combination of these three types of steps, but a scenario usually has distinct blocks of Given, When and Then statements. Scenario steps are defined using text and can have additional table called DataTable or multi-line text called DocString arguments. The scenario steps are a primary way to execute any custom code to automate the application. SpecFlow generates a call inside the unit test method for each scenario step. The call is performed by the SpecFlow runtime that will execute the step definition matching to the scenario step. The matching is done at runtime, so the generated tests can be compiled and executed even if the binding is not yet implemented. You can include tables and multi-line arguments in scenario steps. These are used by the step definitions and are either passed as additional table or string arguments. Tags Tags are markers that can be assigned to features and scenarios. Assigning a tag to a feature is equivalent to assigning the tag to all scenarios in the feature file. A Tag Name with a leading @ denotes tag. If supported by the unit test framework, SpecFlow generates categories from the tags. The generated category name is the same as the tag”s name, but without the leading @. You can filter and group the tests to be executed using these unit test categories. For example, you can tag crucial tests with @important, and then execute these tests more frequently. Background Elements The background language element allows specifying a common precondition for all scenarios in a feature file The background part of the file can contain one or more scenario steps that are executed before any other steps of the scenarios. SpecFlow generates a method from the background elements that is invoked from all unit tests generated for the scenarios. Scenario Outlines Scenario outlines can be used to define data-driven acceptance tests. The scenario outline always consists of a scenario template specification (a scenario with data placeholders using the <placeholder> syntax) and a set of examples that provide values for the placeholders If the unit test framework supports it, SpecFlow generates row-based tests from scenario outlines. Otherwise, it generates a parameterized unit-test logic method for a scenario outline and an individual unit test method for each example set. For better traceability, the generated unit-test method names are derived from the scenario outline title and the first value of the examples (first column of the examples table). It is therefore good practice to choose a unique and descriptive parameter as the first column in the example set. As the Gherkin syntax does require all example columns to have matching placeholders in the scenario outline, you can even introduce an arbitrary column in the example sets used to name the tests with more readability. SpecFlow performs the placeholder substitution as a separate phase before matching the step bindings. The implementation and the parameters in the step bindings are thus independent of whether they are executed through a direct scenario or a scenario outline. This allows you to later specify further examples in the acceptance tests without changing the step bindings. Comments You can add comment lines to the feature files at any place by starting the line with #. Be careful however, as comments in your specification can be a sign that acceptance criteria have been specified wrongly. SpecFlow ignores comment lines. Print Page Previous Next Advertisements ”;