When discussing software engineering, the Agile Development Methodology (ADM) has proven to be a game-changer. Among its several techniques, "Acceptance Driven Development" (ADR) stands out. ADR, also known as Behavior Driven Development (BDD), involves collaboratively exploring, analyzing, and specifying behaviors of software to meet the needs of end users. But what does ADR look like in practice? Let's explore with real-life examples.
Before diving in, it's essential to understand that ADR is Dynamic, expressive, and user-centric. It's all about capturing intended outcomes, not just implementing what's asked for. Now let's take a look at two key aspects of ADR: "Given-When-Then" scenarios and "Gherkin" syntax.
Given-When-Then Scenarios
At the heart of ADR lies the Given-When-Then structure, which breaks down system behavior into input (Given), action (When), and outcome (Then). This pattern organizes our exploration and validation of software behavior.
For instance, consider a simple e-commerce example: a user adds items to their cart and proceeds to checkout.
Cart Management
Using Given-When-Then, we can express this behavior as:
- Given the user has selected several items and added them to the cart
When the user proceeds to checkout
Then the system should display the total price of the selected items.
Here, 'Given' sets the initial state, 'When' triggers an action, and 'Then' verifies the expected outcome.
User Registration Validation
Likewise, for user registration, we might have:
- Given the user provides an email with less than 6 characters
When the user attempts to register
Then the system should display an error message: "Email must be at least 6 characters".
This example showcases the power of ADR in validating edge or error scenarios.
Gherkin Syntax for BDD
Gherkin is a plaintext language used for defining behavior in BDD. It lets us specify behaviors in a human-readable, structured way. Let's convert our previous cart management example into Gherkin syntax:
Feature File for Cart Management
| Feature: | E-commerce Cart Management |
|---|---|
| As: | A user |
| I want: | To see my cart total when checking out |
| Scenario: |
Given I have selected "T-Shirt", "Jeans", and "Shoes" in my cart And the price of each item is $10, $20, and $50 respectively When I proceed to the checkout Then I should see the total cart price is $80 |
Each line starting with "Given", "When", or "Then" represents a single scenario step, making it easy to understand and maintain.
Scenario Outlines in Gherkin
Gherkin also supports Scenario Outlines, allowing us to specify multiple instances of a scenario with different data. For validating discount thresholds:
| Feature: | E-commerce Discounts |
|---|---|
|
Given I have items in my cart totalling a price of | Price | Apply Discount | Expected Total | $100 | Yes | $90 | $200 | No | $200 |
Here, '|' separates the scenario outline from the examples placed into a table.
More complex examples would follow this same structure, with additional tables or steps breaking down the desired behavior into manageable pieces. Ultimately, ADR and Gherkin empower us to create well-defined, readable, and maintainable specifications for our software. By collaborating and exploring behaviors together, we can build software that truly meets the needs of its users.