Quartz 4

Behaviour Driven Development (BDD)

8 min read

Test case

  • The description of a set of actions to be performed on software and an expected outcome Test
    • The execution of a test case, producing a test outcome. Testing
    • The practice of creating, maintaining, executing and evaluating test cases

Why Test?

Detection of defects is probably the oldest reason for undertaking testing activities. Historically, software teams would be divided between developers and testers.

The testers would be given an implementation and a high level description of its intended functionality. They would then develop tests to check for the correspondence between the two. This practice still occurs in software development organisations, particularly where there is a need to demonstrate the independence of testing for audit purposes.

However, in modern software practice, particularly in small teams, the other reasons for testing have become more important. The emphasis has shifted away from identifying and removing defects and towards the prevention of their introduction in the first place as part of a continuous change management system.

Scales of Testing

Testing at different scales is crucial for ensuring software reliability and functionality. Below are the primary types of tests used in software development.

Unit Tests

  • Focus: Unit tests are designed to validate the functionality of a specific module or unit, like a class or a method.
  • Characteristics: Due to the high volume, unit tests must run quickly and efficiently, often making use of test doubles like mocks and fakes to simulate interactions with other parts of the application.
  • Purpose: These tests aim to ensure that each component functions correctly in isolation from others, without the slower activities such as I/O operations.

Integration Tests

  • Focus: Integration tests verify the interactions between integrated subsets of the system’s components.
  • Characteristics: While still utilizing test doubles for certain external services, these tests primarily focus on the data flow and cooperative behavior among combined parts.
  • Purpose: To catch issues that occur when units are combined, which might not be visible in unit testing.

Acceptance (System) Tests

  • Focus: These tests evaluate the system as a whole to ensure it meets the specified requirements.
  • Characteristics: Typically costly and time-consuming, acceptance tests are fewer in number but critical for verifying that the system behaves as intended in a production-like environment.
  • Purpose: To demonstrate compliance with business requirements and document use cases. These tests may include manual execution and often cover non-functional aspects like performance and security.

Behaviour Driven Development (BDD)

  • Overview: BDD enhances the link between technical specifications and business requirements through continuous example-based communication. It uses a structured natural language (Gherkin) to express user stories and scenarios directly linked to test automation.
  • Integration in Testing: Primarily used for system and acceptance testing, BDD articulates requirements in a way that’s understandable by all stakeholders, ensuring the software aligns with user expectations.
  • Lifecycle: The BDD lifecycle involves defining features through user stories, developing scenarios, and translating these into test cases that drive system design and implementation.
  • Considerations: Although BDD can technically be applied to unit or integration testing, the overhead may not always justify its use at these levels. The structured approach helps prevent top-down design biases by integrating feedback and adjustments throughout the development process.

Critical Perspective on BDD

  • Model Skepticism: The typical portrayal of BDD resembles a waterfall process where tests are developed prior to implementation. This can be problematic as it might lead to rigid designs without considering practical feasibility or external constraints.
  • Practical Implementation: More effective approaches might involve developing features concurrently with their implementations, allowing for more adaptive and iterative design processes that better accommodate real-world complexities.

Understanding these testing scales and methodologies helps teams create more robust, user-centric software applications. Each type of test serves distinct purposes, from detailed unit testing to broad acceptance tests, forming a comprehensive evaluation framework throughout the software development lifecycle.

Gherkin

Gherkin scenarios are divided into three phases that mirror the ‘Triple A’ pattern for unit test cases, denoting phases for arranging the objects that will participate in the test (given steps), performing some actions upon them (when steps) and asserting some properties hold after the action (then steps).

Frameworks for Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) frameworks play a critical role in automating the translation of business-readable specifications into executable test cases. Below are key insights into how these frameworks enhance the BDD process.

Challenges in Mapping Scenarios to Test Cases

  • Repetition and Redundancy: Writing test cases directly from Gherkin scenarios can lead to significant repetition since similar steps often appear across multiple scenarios or are repeated within the same scenario.
  • Refactoring Steps: To reduce redundancy, steps within the scenarios can be refactored. Implementations of these steps can be extracted into individual methods, improving maintainability and reducing code duplication.
  • Synchronization Issues: Despite refactoring, a major challenge remains in maintaining the order of steps, as it needs to be consistent in both the Gherkin feature file and the corresponding test case implementation.

Role of BDD Frameworks

  • Automating Step Definitions: BDD frameworks address the redundancy issue by linking Gherkin steps directly to functions or methods in the codebase, known as step definition functions.
  • Reduced Maintenance: With BDD frameworks, developers no longer need to maintain a separate test case for each scenario. Instead, they ensure that there is a corresponding step definition function for each unique step defined in the Gherkin feature.
  • Seamless Execution: These frameworks automate the execution process by selecting and running the appropriate step functions in the correct sequence based on the scenario definition. This automation ensures that the tests are run exactly as specified in the Gherkin steps, preserving the intended behavior and validation logic.

Several frameworks are available that facilitate BDD, each supporting different programming environments:

  • Cucumber: Widely used across many programming languages, Cucumber reads Gherkin files and executes the application against the described requirements.
  • SpecFlow: Primarily for .NET environments, it integrates seamlessly with Visual Studio.
  • Behave: For Python programmers, Behave works well with the native Gherkin syntax.
  • JBehave: A framework suited for Java developers, offering integration with Java-based applications.

Conclusion

BDD frameworks significantly streamline the process of developing and maintaining behavior-driven tests. They bridge the gap between non-technical stakeholders and developers by automating the execution of specifications written in a business-readable language. This leads to more accurate outcomes and adherence to the originally specified requirements, ultimately enhancing the quality and reliability of the software product.

Enhancing BDD Specifications to Minimize Duplication

Efficient Behavior-Driven Development (BDD) requires techniques that minimize duplication and enhance clarity in specifications. Here are some effective strategies and tools that can be utilized within BDD frameworks.

Backgrounds in Gherkin

  • Purpose: Backgrounds are utilized to group common steps that appear in every scenario within a feature file.
  • Functionality: These steps are executed before the first step of each scenario, ensuring that repetitive setup tasks do not clutter the main scenarios.

Parameterized Steps

  • Definition: Step definition functions can be parameterized to handle similar steps with only minor differences, such as variable inputs.
  • Implementation: Parameters like account_name, expected_balance, and amount are passed to the relevant function, allowing a single step definition to accommodate variations.
  • Best Practices: It’s useful to guard parameter values (e.g., using quotes around strings or currency labels) to prevent misinterpretation by the regex patterns used for matching step definitions.

Step Abstraction

  • Overview: While not a direct feature of Gherkin, some BDD frameworks allow steps to be abstracted into composite steps. This approach can reduce duplication by allowing complex steps to be broken down into simpler, reusable components.
  • Challenges: This method can obscure the explicitness of steps in the Gherkin file and may lead to violations of the Arrange-Act-Assert (AAA) pattern. For instance, mixing setup (Given) and action (When) steps can complicate the clarity and maintainability of tests.

Scenario Outlines and Example Tables

  • Utility: Scenario outlines are invaluable for scenarios that repeat the same steps but with different outcomes based on varying input parameters.
  • Execution: Each scenario is executed for each row in the associated example table, effectively testing multiple scenarios from a single template.
  • Integration with Parameterized Steps: Often used alongside parameterized steps, scenario outlines paired with example tables can streamline the creation of multiple test cases from a single outline, reducing redundancy.

Implementation Considerations for Step Functions

  • API Level: Step functions can be implemented directly on the API, serving as a facade to simplify interactions.
  • System Interface: Steps may also be implemented at the system interface level, such as through a user interface or a REST API.
  • Practical Considerations: Directly testing behavior against functional classes rather than through user interfaces is generally more cost-effective and stable, as UIs may change more frequently than underlying business logic.

Tools and Frameworks

  • Selenium and Katalon: These frameworks are specifically designed to mitigate issues related to UI testing in web applications.
  • Django-Behave: An extension for BDD tools that facilitates testing in Django web applications, maintaining the integrity of tests against frequent changes in UI frameworks.

By utilizing these techniques and tools, development teams can enhance the efficiency of their BDD practices, ensuring that tests are both robust and maintainable while minimizing unnecessary duplication.

Graph View

Backlinks