In software engineering, behaviour-driven development (BDD) is a software development process that emerged from test-driven development (TDD). The behaviour-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.
Behaviour-driven development should be focused on the business behaviours 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 behaviours they want to see in the system.
- The developer asks questions based on their understanding of the system, while also writing down additional behaviours 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 UI level test cases. Tools like RSpec (for Ruby) or in .NET, like MSpec or SpecUnit, are popular for Unit Testing following the 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) orSpecFlow (for .NET).
Although BDD is principally an idea about how software development should be managed by business interests and technical insight, the practise 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 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 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, it must fail just like any other test during Surefire or Failsafe execution. After the build, we should be able to get a user-friendly HTML report.
Most of BDD frameworks use common template for writing tests:
given (some context)
when (something happens)
then (some behavioural 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.
