Add reboot.bdd: write Reboot tests in Gherkin with pytest-bdd

[benh]

Adds reboot.bdd, a pytest-bdd layer for testing Reboot applications with Gherkin, plus its test suites.

What a test looks like

Feature: Accounts

  Background:
    Given the application is up

  Scenario: Depositing adds to the balance
    Given an `Account` for "alice" gets created via `open` with `initial_balance: 100`
    When the `Account` for "alice" gets a `deposit` with `amount: 50`
    Then the result has `updated_balance: 150`
    And `balance` on the `Account` for "alice" has `balance: 150`

The test module does from reboot.bdd.steps import * and defines an application fixture returning the Application under test. Each scenario runs against a fresh started Reboot harness, and each step's call runs on a fresh ExternalContext (the way each external call in production arrives with its own) unless the scenario creates one to share via Given a shared context.

Built-in steps

• Given the application is up
• Given a shared context
• Given an `Account` for "alice" gets created via `open` with `initial_balance: 100` (usable as When too)
• When the `Account` for "alice" gets a `deposit` with `amount: 50` (usable as Given too)
• When the `Account` for "bob" attempts a `withdraw` with `amount: 50`
• Then the attempt aborts with `OverdraftError` where `amount: 20`
• Then `balance` on the `Account` for "alice" has `balance: 150`
• Then `balance` on the `Account` for "ghost" aborts with `StateNotConstructed`
• When `get_owner` on the `Account` for "frank" has `owner.name` saved as "$owner_name" (later steps say $owner_name in a state's ID or as a property value)
• Then the result has `updated_balance: 150` (as Given/When, saves instead)

The property grammar

A has/where/with list holds JSON object members, `name: value` each in backticks, separated by commas or and. Values are JSON (an object or array calls through the method's request type; on assertions it compares as the complete message); a dotted name nests when calling and reaches into the response when asserting; a malformed or unknown property raises instead of being skipped. In a has or where list a clause can instead be `name` saved as "$name": a Then has/where asserts and refuses saving clauses, a Given/When has saves and refuses comparing clauses.

Readers are only read via `reader` on ...; gets a/attempts a refuse them with a pointing error, and the reader steps refuse writers likewise (whether a method is a reader comes from the generated reactively() surface, which serves exactly the unary readers). Reading records the result, so "the result" always means the most recent call any step made.

State types are resolved from the Application's servicers by class name, or by full state type name (e.g. bank.v1.Account) when more than one state type goes by the class name; both proto and pydantic codegen are supported.

How it works

pytest and pytest-bdd are synchronous while everything Reboot is async, and we deliberately don't use pytest-asyncio (pytest-bdd never awaits step functions, so it wouldn't help anyway). Instead, each scenario runs one event loop on a background thread, created before its first step and closed after its last: one loop per scenario, matching both unittest.IsolatedAsyncioTestCase (one loop per test) and production (one application runs on one event loop under rbt dev run and rbt serve), so nothing a scenario leaks can run on into later scenarios. The loop's teardown mirrors IsolatedAsyncioTestCase: cancel pending tasks, shut down async generators, close.

The reboot.bdd given/when/then/step decorators work like pytest-bdd's except that the decorated step function may be async def, so custom developer steps get the same treatment as the built-ins (exercised by the custom steps in tests/reboot/bdd/bdd_tests.py and tests/reboot/bdd/pydantic/bdd_tests.py).

Also in this PR

• Reboot.stop() now cancels (via wait_for_tasks) the monitor_event_loop() task that start() creates. IsolatedAsyncioTestCase hid this leak by closing its per-test loop; on a longer-lived loop every harness left a pending task behind. Ran //tests/reboot:external_context_tests_py to check for regressions, but this touches every harness user, so please look closely.
• pytest==8.4.2 and pytest-bdd==8.1.0 added to reboot/requirements.in (and mypy.ini ignore sections for both).

Testing

bazel test //tests/reboot/bdd:bdd_tests_py //tests/reboot/bdd/pydantic:bdd_tests_py (proto and pydantic suites, plus unit tests for name collisions, unknown properties, and reader detection).

Not yet done (follow-ups)

• The published wheel should probably get pytest-bdd as a reboot[bdd] extra rather than a hard dependency; only the Bazel side is wired here.
• Docs (a testing-bdd.md skill reference), state assertions via a test-only raw-state read (e.g. Then the state of the `Account` for "alice" has `balance: 70` ), reactive eventually variants of the assertion steps, identity/auth steps, task steps, and failure/recovery steps.

🤖 Generated with Claude Code

https://claude.ai/code/session_015whh5EmdU8PAoxSevMRn5m

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This pull request is currently open (not queued).

How to merge

To merge this PR, comment /aviator merge or add the mergequeue-ready label.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.