Behavior-Driven Development (BDD) is a software development methodology that can help resolve common communication issues between business and technical people by:
Encouraging collaboration
Working iteratively to promote fast feedback
Creating reliable documentation
Through a three step system of Discovery, Formulation and Automation, teams that successfully implement BDD achieve tight collaboration between development and product organizations, as they agree upon their problem domain, and are able to confidently create, update and test applications at speed.
Cucumber is a framework that allows teams to write tests with executable specifications written in plain text. Using a complementary framework like Gherkin, teams can write test cases in plain, spoken English. From there, Cucumber can tie these plain text test scenarios to the corresponding test case (in this example, written in Ruby). Those tests can run against the application or feature, and Cucumber provides results back to teams.
Simply put, BDD framework is a testing methodology, and Cucumber is a technology that can help with its adoption. They can break down walls between technical and non technical teams, and help affect true cultural change as quality becomes a business-level imperative to be owned by everyone. However, there are some questions you need to answer before adopting a BDD methodology in order to ensure success:
Who is responsible for testing automation scenarios? - Who is creating the actual BDD spec files in your organization? Many would assume that it’s the automation engineer. But in the BDD framework, that might not be the case. In a Behavior Driven Development team, the person/team who knows the behavior of the system should drive test scenario creation. For some teams, that could mean the Business Analyst, the developer, the Product Owner, or someone else. It’s crucial that you identify who in the organization best understands the behavior of your application, and insert them directly into the creation of these scenarios.
Can we afford extra dependencies? - In software development, we strive towards having our modules doing less while limiting the number of dependencies, as every dependency is a chance for something to go wrong. By its nature, BDD and Cucumber create extra layers of abstraction to ensure that everyone is involved in the quality process. For your team, this might be just what you need to adopt testing automation at scale. But if these extra steps might cause issues or bottlenecks, then it might make sense to look for other options.
Is parallelization important? - Simply put, Cucumber is not currently optimized to perform parallel testing. It parallelizes at the feature file level, implying that if you want to run 50 tests in parallel, you need to have 50 feature files. That’s a lot of feature files. Teams are often left spending time and money to design a sharding mechanism that will split every test method into its own thread so that they can run scenarios in parallel, rather than feature files. If you use a BDD automation tool, you automatically have a disadvantage in one of the key tenants of testing automation. To overcome this disadvantage you must do extra work.
Are we committed to learning new syntax? - In order to gain the collaborative benefits of BDD automation, it’s important to commit to the principles of the tools that enable it. One example of this is Gherkin, the framework used by Cucumber to connect to tests written in Ruby. Gherkin has very specific syntax requirements to ensure that tests are readable, even by non technical team members. These rules include: write all steps in third-person point of view, write steps as a subject-predicate action phrase, and more. If you want readable results, you must have readable tests, so it’s important to gain buy in from teams so that they adhere to these principles in order to gain the true benefits of BDD
As the Cucumber documentation states, “BDD aims to narrow the communication gaps between team members, foster better understanding of the customer and promote continuous communication with real world examples”. There are plenty of examples where BDD and Cucumber have achieved just that. But it’s important to understand your organization’s requirements, and if BDD fits that need.
Related Content:
