Behavior-Driven Development

Source:- digility.com

Another great knowledge share from the Digilty/Mastek team. The latest webinar focused on Behavior Driven Development in automated testing using the Cucumber framework. Here are the top five takeaways from the session, led by Tripti Mittal:

What is BDD

BDD (Behavior-Driven Development) is a fusion and improved enhancements of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development). Unlike TDD where testing & development are conducted in isolation, BDD is a collaborative exercise that involves product owners, business analysts, testers, and developers which helps to ensure that all project members understand precisely what needs to be done and implemented.

Agile & BDD

BDD can be used in non-agile projects. They are techniques to design requirements and test cases, which can be automated. Often they are used in agile software development because they provide a fast response sequence for requirements and code under development. In addition, since Agile development does not have a separate testing phase, BDD helps in introducing automation testing at an early stage enabling teams to easily protect themselves from costly regressions.

A BENEFIT OF USING BDD

BDD adds structure and objectivity to requirements and acceptance tests by adding real data in Gherkin format. This allows teams to communicate better and focus on real world examples and not on abstract and imperative requirements. Thus bridging the gap between Business and IT.

CUCUMBER FRAMEWORK

Cucumber is a tool that implements a behavior driven design workflow. It does not care about the name or the description but rather the purpose is simply to provide a place where you document important aspects of the feature such as a brief explanation and a list of business rules.

Organizations falsely believe that popular BDD tools provide the secret ingredient that will radically change the way that they define, build, and maintain their automated tests. We need to understand that these tools are simply a concept layer that allows us to better define our needed tests up front and minimize redundancies in our tests. It will not fix problems like:
• Not enough testers with the know-how to build automation.
• Inability to build robust and complete test coverage, whether it is automated or manual.
• Applications with low testability (i.e. lacking API’s for service level tests, improperly named
objects, old frameworks like Flash)