Idea: First-class Gherkin (.feature) support in Pest

[lkmadushan]

Title suggestion

Native Gherkin / .feature file support — replace the need for Behat

TL;DR

Let Pest parse and execute .feature files directly, with step definitions written in Pest's normal expressive style. Today, teams that want both unit/feature tests and BDD-style acceptance tests have to run Pest and Behat side-by-side — two runners, two configs, two reporters, two mental models. A first-party Gherkin layer in Pest would collapse that into one tool.

This has become noticeably more valuable in the AI-assisted ("vibe coding") workflow, where Gherkin is an excellent specification handoff format between human and LLM.

Problem

In a typical Laravel/PHP project today, the BDD setup looks like:

• phpunit.xml + tests/ for Pest
• behat.yml + features/ + FeatureContext.php for Behat
• Two CI steps, two coverage configs, two failure formats
• Step definitions live in a separate world from the rest of the test suite — different assertion library, different helpers, different bootstrapping

Concretely, a project I'm working on right now has both ./vendor/bin/pest and ./vendor/bin/behat wired into CI, with overlapping bootstrap code. Maintaining two parallel test stacks just to get Gherkin is a real cost.

Proposal

Pest discovers *.feature files (configurable path, e.g. features/) and executes them as test cases. Steps are defined in PHP using Pest's existing DSL — something like:

// tests/Steps/GameSteps.php

use function Pest\Gherkin\{given, when, then};

given('a seeded game where the wumpus is in room :room', function (int $room) {
    $this->game = Game::seeded(wumpusRoom: $room);
});

when('the player enters :input', function (string $input) {
    $this->output = $this->game->run($input);
});

then('the output should contain :text', function (string $text) {
    expect($this->output)->toContain($text);
});

Run with the same command everyone already uses:

./vendor/bin/pest

Output, filtering (--filter), parallelism (--parallel), coverage, and plugins all come for free because it's just Pest.

Example feature file (unchanged from Behat-style)

Feature: Shooting crooked arrows
  As a player
  I want to shoot a crooked arrow through up to 5 rooms
  So that I can kill the wumpus without entering its room

  Scenario: A straight arrow that hits the wumpus wins
    Given a seeded game where the wumpus is in room 5
    When the player enters "S" then "1" then "5"
    Then the output should contain "Aha! You got the wumpus!"

Why now: AI-assisted development

Gherkin's value has gone up in the LLM era, not down:

1. Gherkin is a near-perfect spec format for LLMs. Given/When/Then is unambiguous, structured, and human-readable. A non-technical stakeholder can write or review a .feature file; an AI coding assistant can read it and generate both step definitions and production code from it.
2. The natural workflow is: human (or human + AI) writes .feature → AI writes step defs → AI writes implementation → tests go green. Today that workflow is awkward because the AI has to context-switch between Behat conventions and the Pest conventions used by the rest of the suite.
3. One runner, one mental model dramatically reduces the surface area an LLM has to keep in context — fewer hallucinated configs, fewer "did you mean Behat or Pest?" mistakes.

A unified Pest+Gherkin would make Pest the default acceptance-testing tool for AI-driven PHP development.

Why Pest specifically

• Pest already has the expressive, closure-based DSL that maps cleanly onto Gherkin steps.
• Pest's higher-order tests, datasets, and architectural testing are conceptually adjacent to scenario outlines and tables — there's a coherent design story.
• The ecosystem (plugins, Laravel/Livewire integration, parallel runner) all immediately benefit Gherkin scenarios.

Out of scope / open questions

• Full Behat compatibility is not required — a clean, Pest-idiomatic step API is more valuable than a drop-in Behat replacement.
• Parameter type system: start with simple typed placeholders (:room as int, :text as string), expand later.
• Hooks (Background, Before, After) map naturally onto Pest's beforeEach/afterEach.
• Could ship initially as an official plugin (pestphp/pest-plugin-gherkin) before being merged into core.

What I'd love feedback on

1. Is there appetite from the maintainers for this as a first-party plugin?
2. Would the community prefer a Behat-compatible step syntax, or a fresh Pest-native one?
3. Anyone already prototyping this?

---

Posting this because I'm currently running Pest and Behat side-by-side on a Laravel project and the duplication is painful — especially when handing context to an AI assistant. Happy to help prototype if there's interest.