Sign in
Menu

Keep tests in Reflow
or in your repository.

Start with shared tests in Reflow to try it without adding files to Git. Your team can choose repository storage later. Targets, credentials and plugin connections stay private on the device that runs the tests.

Follow the complete setup guide

Choose where new tests are saved.

Owners and admins choose the team default during onboarding or in Team settings. Changing it affects new tests. Existing tests stay where they are until you move them.

A collection can include both locations. Plan and apply select its runnable tests together; pass a test slug, ID or registered path to run a subset.

Choose storage and move tests
Collection and test selection
reflow config get test-storage
reflow flows list
reflow plan invite-member
reflow apply invite-member

Describe the test
and its setup.

The prose tells a human or agent what the flow means. The RFL steps execute. needs names upstream flows; covers declares relevant source paths.

Choose exact plugin requirements from your installed catalog. This example assumes a seed-data flow and a Browser binding named site; adapt its selectors to your app.

Flow reference
invite-member: saved in Reflow or the repository
---
name: Team invitation
url: /settings/team
needs: [seed-data]
covers: [src/team/**]
providers:
  site: Browser
plugins:
  - name: Browser
    sourceCommit: 5852a91f8ba9f4c73585a5984a96117a159c068f
    descriptorDigest: c86d7af94675fed13771b48b5f75f60a4988a2cf4158dd6d211e0f651006e505
---

The owner can invite a member and choose their role.

### Open the invitation
```rfl
site.open url="/settings/team"
site.click selector="[data-testid=invite-member]"
site.expect selector="h2" text="Invite a teammate"
site.snapshot name="team-invitation" selector="[data-testid=invitation-form]"
```

Keep credentials
out of flow source.

Bindings connect provider aliases to local configuration. The same flow can use different URLs, database credentials and working directories on each device.

This Browser binding targets a local app. Enable database writes explicitly in the database’s private binding.

Private bindings.json
{
  "site": {
    "provider": "Browser",
    "configuration": {
      "targetUrl": "http://localhost:3000",
      "browser": "chromium"
    }
  }
}

Keep this file private. Pass its absolute path with --bindings.

Select the application to test.

target selects the application and starts fresh execution state. Use it once for a development session. plan explains the decisions; apply executes.

Reuse requires matching inputs and eligible completed evidence in the same target session. Use taint when an external change requires fresh execution.

Target setup commands
reflow init
reflow target http://localhost:3000 \
  --group my-app --collection <collection-id> --repo . \
  --bindings /absolute/path/to/bindings.json
Reuse completed work. Rerun what changed.CLI replay
$ reflow plan
Target: no URL (non-browser flows)
Group: order-lifecycle (device)
reuse   seed: Step 1: Completed with matching target, inputs and evidence
reuse   place-order: Step 1: Completed with matching target, inputs and evidence
reuse   refund: Step 1: Completed with matching target, inputs and evidence
reuse   verify-refund: Step 1: Completed with matching target, inputs and evidence
Plan: 0 to run, 4 to reuse, 0 waiting, 0 blocked.

Connect the agent
you already use.

MCP exposes the same execution controller, application knowledge, saved flows, plugins and review evidence.

Use the same repository, private profile and connection settings in your CLI and agent configuration. Reflow discovers the local service automatically.

See the agent setup

Publish results
to the pull request.

Pin the reporting integration from Reflow’s source repository and configure your application fixture with its Reflow connection and private bindings. The execution job runs PR code with read-only repository permissions. A separate trusted publisher updates the PR comment.

Set up GitHub reporting