In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). The behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.
Behavior-driven development should be focused on the business behaviors your code is implementing: the “why” behind the code. It supports a team-centric (especially cross-functional) workflow. The agile BDD work really well when a developer and either the Agile product owner or a business analyst sit down together and write pending specs (to be filled in later by the developer) in a plain text editor:
- The business person specifies behaviors they want to see in the system.
- The developer asks questions based on their understanding of the system, while also writing down additional behaviors needed from a development perspective.
Ideally, both parties can refer to the list of current system behaviors to see if this new feature will break existing features.
BDD is popular and can be utilized 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).
Although BDD is principally an idea about how software development should be managed by business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process. Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.
The way BDD works is really simple – it is a bridge between business language (User Stories) and automatic tests (JUnit, TestNG). In order to keep the documentation in sync with the code – we need to run it as a test in Continuous Integration build (Jenkins, Bamboo). Test specification should be written in the business-friendly form, for example in some text or HTML file. This way it will be easily accessible to Business Analysts. On the other hand in must fail just like any other test during Surefire or Failsafe execution. After the build, we should be able to get user-friendly HTML report.
Most of BDD frameworks use common template for writing tests:
given (some context) when (something happens) then (some behavioral validation)
Example of BDD Test.
Cucumber is one of the best BDD frameworks which vastly used in the market. The main feature of the Cucumber is that it is mainly focused on Acceptance testing. It is so easy to read and write the cucumber test cases with its feature it brings business users in the test process. Cucumber features are so easy that for the non-technical person it is also easy to read and understand the test flows & requirements.
Feature: Sign up in Gmail Scenario: User can signup in gmail successfully. If user is new the it should greet user for the new account and also show its features. Given I chooses to Sign up. When I sign up with valid credentials. Then I should redirect to my gmail inbox. And I should see current list of my emails in inbox. Scenario: Sign up with invalid credentials When someone enters wrong password for it's gmail account. Given I chooses to Sign up. But I enter invalid password for my email account. Then I should receive a validation message for invalid password. And I should be asked to enter my password again.