Session Selection

How Session Selection Works

Reccy replays recorded sessions and tracks:

• Lines of code executed
• React components rendered
• Route patterns accessed

From this data, Reccy continuously selects a combination of sessions that collectively cover all distinct code paths—including feature flag branches, conditional logic, and component variants. This curated set forms your test suite.

As your app changes and new sessions are recorded, Reccy automatically updates the selection to cover new features.

Configuring Session Count

To adjust the number of sessions:

1. Visit your project dashboard
2. Select the Selected Sessions tab
3. Click Configure

Tip

Select enough sessions so that the marginal session adds no extra coverage. Reccy provides guidance in the UI.

Test runs in Reccy cloud typically complete in under 2 minutes regardless of session count.

Viewing Coverage

To see what your tests cover:

1. Go to your project page
2. Click View coverage & snapshots

You’ll see:

• Screens covered, organized by route
• Sub-variants (same screen, different states or visible components)
• Per-file coverage (if source maps are provided)

Manual Session Selection

Automatic selection is recommended, but you can pin specific sessions:

1. Navigate to the Sessions tab
2. Select a session
3. Click Add to selected sessions

Pinned sessions will always run alongside automatically selected sessions.

Why Localhost Sessions Don’t Cause Issues

You might worry that sessions from incomplete branches on localhost will cause false failures. Reccy handles this through:

1. Filtering — Session selection algorithms filter out broken sessions that don’t add meaningful coverage

2. Replay-time baselines — Screenshots are taken at replay time, not record time. When you open a PR, Reccy replays sessions against both commits. A session clicking on an unreleased feature will produce identical screenshots on both commits, resulting in no diff.

Handling Stale Network Responses

Recorded sessions include the network responses from when they were captured. If you make breaking API changes:

• Old sessions with outdated responses are automatically swapped for newer sessions covering the same code paths
• This ensures tests remain deterministic without manual maintenance