Evaluation of Gherkin (Given/When/Then) syntax and alternatives for the organization’s pseudocode initiative. Originally compared with IEC 61131-3 Structured Text (removed as out-of-scope), then pivoted to evaluating alternatives that could replace or complement Gherkin.
Gherkin Strengths
Natural language readable by non-technical stakeholders
Given/When/Then maps to precondition/action/outcome
Strong communication bridge between Business Analysts and Developers
Gherkin Weaknesses
Tax on Prose — Maintenance cost of natural language parsed by regex
Linear structure — Poor at expressing combinatorial logic (50 lines for what a decision table shows in 5)
JSON/XML clumsiness — Data payloads look messy in feature files
Alternative Evaluation
Tool
Verdict
Best For
Robot Framework
Excellent alternative
Complex/math-heavy logic — tabular inputs superior to text
Karate DSL
Strong addition
API-heavy data flow — native JSON support
Pytest-bdd
Risky for pseudocode
100% developer teams only — loses business-readable layer
Mabl/AI Recorders
Remove from scope
Post-implementation validation, not pre-implementation design
Decision Tables
Strong addition
Combinatorial logic — cleaner than multiple Gherkin scenarios
Mermaid.js flowcharts
Visual pseudocode
Happy path + error paths in single visual file
Critical Distinction: Specification vs. Execution
The pseudocode initiative is about defining logic before coding (specification), not testing after implementation (execution). This eliminates Mabl, Functionize, and pure code-based frameworks from consideration.