Tyapkin
Capkin

Compatibility And Backends

How Capkin stays valid Gherkin while generating adapters for other executable spec frameworks.

Compatibility And Backends

Capkin is compatible with Gherkin at the syntax layer:

Capkin files are valid .feature files.
Any standard Gherkin parser can parse them.
Capkin adds semantic validation after parsing.

This is not the same as saying every Cucumber-style runner can execute Capkin semantics automatically. Standard runners need step definitions. Capkin can generate those definitions or generate framework-specific specs from CAP IR.

Canonical Flow

Capkin .feature
  -> Gherkin AST
  -> Capkin Step Expressions
  -> Semantic Binder
  -> CAP IR / protobuf
  -> runtime and documentation backends

Supported Compatibility Targets

Cucumber / Cucumber.js:
  generated step definitions and fixtures

Behave:
  generated Python step bindings

Behat:
  generated PHP context bindings

Reqnroll:
  generated .NET bindings

Karate:
  generated API/protocol test features

Gauge:
  generated Markdown specifications

Fumadocs / Markdown:
  human documentation and rendered execution walkthroughs

Why Not Karate Or Gauge As The Core?

Karate is a strong executable API testing DSL. Gauge is a strong Markdown-first specification runner. Both are useful, but both are execution/reporting ecosystems.

Capkin needs to be more neutral:

Gherkin is the portable scenario shell.
Capkin is the typed protocol language.
CAP IR is the framework-independent contract.

Karate and Gauge should be compiler targets, not the canonical protocol source.

Extension Contract

Each Capkin extension should define:

  • name and version;
  • parameter types;
  • accepted step expressions;
  • semantic validation rules;
  • CAP IR mappings;
  • protobuf bindings when needed;
  • runtime/backend support matrix;
  • conformance examples.

Example:

capkin-compliance@0.1
  parameter types:
    {wallet}, {network}, {riskScore}, {policy}

  expressions:
    When Compliance evaluates guard {policy}
    And the policy rejects wallet {wallet} when it is in Badlist
    And the policy rejects network {network} when RiskScore exceeds {int}

  mappings:
    GuardSpec
    PolicyPredicate
    TraceProofExpectation

This keeps the core small while allowing real-world domains to become rich.

On this page