Skip to main content

Testing Specification Strategies: Gherkin vs Alternatives

This document evaluates the "Gherkin Strategy" against viable alternatives for defining automated test specifications in the WepNG context.

1. The Core Problem​

We want to:

  1. Document the "Hidden Rules" of the legacy system.
  2. Verify these rules with automated tests.
  3. Avoid creating documentation that immediately becomes obsolete (dead text).

2. Options Comparison​

Option A: Gherkin (Reqnroll/SpecFlow) - The Current Plan​

Writing .feature files in plain English, mapped to C# code via Regex.

  • Format: Given a Fee... When created... Then invalid
  • Pros:
    • Readable: Can be read/written by POs/Analysts.
    • Living Doc: "The Spec IS the Test".
    • Framework Agnostic: The concept (Cucumber) is universal.
  • Cons:
    • "The Glue Tax": Maintaining the mapping between Text and C# (Step Definitions) is tedious.
    • Context Switching: Developers jump between .feature and .cs.
    • Rigid: Complex data setups can be awkward in text tables.

Option B: Fluent BDD (LightBDD / FluentAssertions) - Code-First BDD​

Writing tests in C#, but structured to read like specifications.

  • Format: 
    Runner.RunScenario(
        _ => Given_a_fee_with_code("X"),
        _ => When_I_create_it(),
        _ => Then_it_should_fail()
    );
  • Pros:
    • Dev-Friendly: Pure C#. No "glue" code. Refactoring works 100%.
    • Report Generation: Tools like LightBDD generate HTML reports that look exactly like Gherkin.
    • Speed: Faster to write for developers.
  • Cons:
    • Scary for Non-Tech: It's still C# code (curly braces, lambdas). POs won't edit this.

Option C: Plain xUnit + Naming Convention - The Simplest Path​

Standard Unit/Integration tests with disciplined naming.

  • Format: public void Should_Reject_Creation_When_FeeCode_Is_Duplicate()
  • Pros:
    • Zero Overhead: Standard .NET practice.
    • Flexible: Full power of C#.
  • Cons:
    • Not a "Spec": Hard to generate a readable "Business Document" from it.
    • Spaghetti Risk: Without BDD structure, tests tend to become messy procedural code.

Option D: Markdown Specifications (Manual) - Doc-Only​

Write .md files for specs, write separate Tests.

  • Format: specs/Feev2.md + tests/FeeTests.cs
  • Pros:
    • Total Freedom: Docs can look like anything (images, diagrams).
  • Cons:
    • Dead Docs: The code will diverge from the doc. There is no automated link.
    • Double Work: Must update both places.

3. Recommendation​

If the priority is "Living Documentation" accessible to Business: -> Option A (Gherkin) is the standard choice.

If the priority is "Developer Velocity" but we still want "Readable Reports": -> Option B (LightBDD) is excellent. It generates the docs from the code, skipping the Regex maintenance.

If we just want "Automated Tests": -> Option C (Plain xUnit) is enough.