Abstract
Behavior-Driven Development (BDD) has established itself as a popular approach for defining requirements and validating software, mainly due to its promise of aligning business, development, and testing through a simple, behavior-oriented language. However, the large-scale adoption of BDD, especially in complex corporate environments, has highlighted practical limitations related to semantic ambiguity, maintainability, and misuse as a mere automation layer.
This article introduces RCt2 (Rich Case Test – Tier 2) as an evolutionary and pragmatic proposal. RCt2 is not positioned as an attack on BDD, but as a model that preserves its fundamental principles while correcting gaps observed in practice, offering greater conceptual clarity, technical rigor, and long-term sustainability.
1. BDD: Original Proposal and Distortion in Practice
BDD emerged as a natural evolution of TDD, advocating that development should be guided by the system's expected behavior, described through clear examples and discussed before implementation.
In its original proposal, BDD emphasizes:
- Conversations before code
- Examples as specification
- Clarity of business rules
- Communication between areas
However, in market practice, BDD has often been used as:
- A standardized format for test cases
- A rigid contract between areas
- A synonym for Gherkin-based automation
This shift in usage is the root of many of the problems currently observed.
2. Criticisms from BDD's Creator
Dan North, the creator of BDD, has publicly stated that the problem is not with the concept of BDD, but with how it has been adopted and commercialized by the market.
Key criticisms include:
- The overvaluation of the Gherkin language to the detriment of conversation
- The unrealistic expectation that business areas would write technical scenarios
- Long, fragile, and difficult-to-maintain scenarios
- The use of BDD as a mere test automation mechanism
These criticisms reinforce that BDD failed not because of its core idea, but because of its practical application in real-world environments.
3. The Core Problem: Semantic Ambiguity
One of the main challenges of BDD at scale is the ambiguity inherent in the use of the Then keyword.
Gherkin Example:
\gherkin
Scenario: Successful login with valid credentials
Given the user is on the login screen
When they enter a valid username and password
Then the system should allow access
\\
The statement “allow access” can mean:
- Correct interface display?
- Screen redirection?
- Session creation?
- Data persistence?
- Fulfillment of the business objective?
The model does not force the author to differentiate these aspects, transferring the ambiguity to those who implement or maintain the tests.
4. The Conceptual Basis of RCt2
RCt2 is founded on the classic distinction presented by Glenford Myers between Verification and Validation:
- Verification: are we building the product correctly?
- Validation: are we building the right product?
In RCt2, this distinction ceases to be merely conceptual and becomes structural and mandatory within the test case.
5. Structure and Keywords of RCt2
RCt2 adopts a clear hierarchical structure:
- Scenario: defines the test objective
- Steps: logical blocks of the flow
- Substeps: explicit actions, verifications, and validations
Each substep uses a keyword with unique semantics:
| Keyword | Definition |
|---|---|
| Prepare | Defines preconditions or necessary data setup for the step to be executed. It does not represent an action or a validation. |
| Execute | Represents the physical or logical action that moves the test flow, such as clicks, form filling, navigation, or API calls. |
| Verify (Verifique) | Assesses technical or interface compliance: masks, formatting, messages, visual states, and technical rules. |
| Validate (Valide) | Confirms the delivery of business value: process success, data persistence, permissions, redirections, and functional results. |
| Observe | Records relevant secondary behaviors that are not acceptance criteria, such as response time, animations, or logs. |
This explicit separation eliminates conceptual overlap and reduces subjective interpretations.
6. Comparative Example: BDD vs RCt2
BDD Example (Gherkin)
\gherkin
Scenario: Purchase with credit card
Given the user has a product in the cart
When they finalize the purchase providing a valid card
Then the purchase should be successful
\\
The success criterion is generic and open to multiple interpretations.
Equivalent RCt2 Example
\`markdown
Scenario: Purchase with credit card
Step 1: Finalizing the purchase
- Prepare: authenticated user with product available in stock
- Execute: fill in valid credit card details
- Verify: if the total value displayed matches the sum of the product and shipping
- Execute: click the “Pay” button
- Validate: if the order is created successfully and the user is redirected to the confirmation screen
- Observe: if the confirmation email is sent to the user
`
\In this model, technical and business criteria are explicitly separated.
7. Gaps in BDD that RCt2 Fills
RCt2 directly addresses gaps observed in the practical adoption of BDD:
- Semantic ambiguity of
Then - Difficulty of maintenance in long scenarios
- Mixing of technical and business criteria
- Excessive fragility in automation
By making these distinctions explicit, RCt2 reduces noise and increases the sustainability of tests.
8. RCt2 is not Anti-BDD
RCt2 preserves BDD's fundamental principles:
- Focus on behavior
- Use of examples
- Clarity of intent
The difference lies in the honesty about its usage: RCt2 assumes that test cases are technical artifacts that require semantic precision.
These criticisms do not invalidate BDD as a discovery practice, but they highlight its limits when used as a technical test artifact.
9. RCt2 Applied to Test Automation
One of the most relevant differentiators of RCt2 is that it is "automation-ready" by design. The model does not adapt the test to automation later; it is born structured to be converted into code clearly, predictably, and sustainably.
In RCt2, each keyword has an explicit responsibility, which eliminates common ambiguities in BDD-based automation.
| RCt2 Keyword | Role in Automation |
|---|---|
| Prepare | Setup, fixtures, state or data preconditions |
| Execute | Action (UI, API, service, or integration) |
| Verify (Verifique) | Technical assertion (interface, contract, technical rules) |
| Validate (Valide) | Business assertion (value delivered, rule applied) |
| Observe | Log, metrics, evidence, and monitoring |
This direct mapping reduces the coupling between text and implementation and prevents automation from inheriting ambiguities from the writing model.
10. RCt2 and Maintainability of the Automated Suite
In traditional BDD-based automation, it is common to observe problems such as:
- Excessively generic or specific steps
- Intensive use of regular expressions
- Difficulty in refactoring
-
Thenconcentrating multiple responsibilities
RCt2 eliminates these fragilities by imposing, by definition:
- Separation between action and assertion
- Separation between technical and business criteria
- Explicit and controlled setup
As a result, the automated suite becomes more stable, readable, and less costly to maintain over time.
11. RCt2 Beyond UI: API, Services, and Integrations
RCt2 is not a model restricted to interface testing. Its structure naturally applies to API, service, and integration testing, aligning with the test pyramid.
API Example:
- Prepare: service available and initial database state
- Execute: perform POST call to the order creation endpoint
- Verify: HTTP status and conformity of the response schema
- Validate: order created correctly with applied business rules
- Observe: response time and processing logs
This example demonstrates that RCt2 is a test model, not a screen model.
##12. Conceptual Diagram: RCt2 → Automation
The conceptual flow of RCt2 applied to automation can be represented as follows:
\
[Prepare]
↓
[Execute]
↓
[Verify]
↓
[Validate]
↓
[Observe]
\\
- Prepare establishes the initial state
- Execute moves the flow
- Verify ensures technical compliance
- Validate confirms value delivery
- Observe collects information without impacting the test result
This flow reinforces the clarity of responsibilities and facilitates mapping to automated code.
13. Practical Benefits of RCt2
Among the main observed benefits:
- Semantic clarity
- Improved maintainability
- Ease of automation (Execute = action, Verify/Validate = assertion)
- Better technical and business traceability
14. Conclusion
RCt2 emerges as a pragmatic response to the limitations of BDD in real-world environments. It does not attempt to artificially simplify the complexity of software, but to organize it explicitly and sustainably.
More than a new writing format, RCt2 represents a conceptual evolution: less ambiguity, more intent; less promise, more clarity.
Top comments (0)