Tools: RCt2 – A Pragmatic Evolution of BDD for Software Test Cases

BDD Example (Gherkin) ## Equivalent RCt2 Example 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: However, in market practice, BDD has often been used as: 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: 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 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: 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: 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: Each substep uses a keyword with unique semantics: This explicit separation eliminates conceptual overlap and reduces subjective interpretations. 6. Comparative Example: BDD vs RCt2 \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. \`markdown Scenario: Purchase with credit card Step 1: Finalizing the purchase 7. Gaps in BDD that RCt2 Fills RCt2 directly addresses gaps observed in the practical adoption of BDD: 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: 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. 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: RCt2 eliminates these fragilities by imposing, by definition: 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. 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] \\ This flow reinforces the clarity of responsibilities and facilitates mapping to automated code. 13. Practical Benefits of RCt2 Among the main observed benefits: 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. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Conversations before code - Examples as specification - Clarity of business rules - Communication between areas - A standardized format for test cases - A rigid contract between areas - A synonym for Gherkin-based automation - 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 - Correct interface display? - Screen redirection? - Session creation? - Data persistence? - Fulfillment of the business objective? - Verification: are we building the product correctly? - Validation: are we building the right product? - Scenario: defines the test objective - Steps: logical blocks of the flow - Substeps: explicit actions, verifications, and validations - 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. - Semantic ambiguity of Then - Difficulty of maintenance in long scenarios - Mixing of technical and business criteria - Excessive fragility in automation - Focus on behavior - Use of examples - Clarity of intent - Excessively generic or specific steps - Intensive use of regular expressions - Difficulty in refactoring - Then concentrating multiple responsibilities - Separation between action and assertion - Separation between technical and business criteria - Explicit and controlled setup - 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 - 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 - Semantic clarity - Improved maintainability - Ease of automation (Execute = action, Verify/Validate = assertion) - Better technical and business traceability