Selenium → browse-tests Migration: Batch Assignments¶
Companion to browser-test-migration-checklist.md and browser-test-migration-plan.md.
Operational status: for current
.raklet.netmatrix-run failures and the PRs that address them, see browse-test-failures-status.md.
Goal: run multiple LLM agents (Claude, Codex, Cursor) in parallel, each owning one feature folder so no two agents touch the same file. Each batch produces one branch + one PR.
Total Selenium tests to migrate: 304 (active), across 17 feature folders.
Wave 1 — Read-only (55 tests, 4 batches)¶
Safest. Runs on .raklet.org or .raklet.net. No data mutation, no fixtures, no cleanup risk.
| Batch | Feature area | Approx tests | Target suite | Branch name |
|---|---|---|---|---|
| RO-1 | Raklet.UI.Test.1/ContactTests (read-only rows only) |
~10 | admin-regression | gercek1/migrate-contacts-readonly |
| RO-2 | Raklet.UI.Test.1/LoginTests + Raklet.UI.Test.3/UrlRedirectTests + Raklet.UI.Test.3/ReportsTests + Raklet.UI.Test.2/AppStoreTests |
~13 | admin-regression | gercek1/migrate-login-redirects-readonly |
| RO-3 | Raklet.UI.Test.3/SettingsTests (read-only rows only) |
~15 | admin-regression | gercek1/migrate-settings-readonly |
| RO-4 | Raklet.UI.Test.4/SocialTests + Raklet.UI.Test.5/EventsTests (read-only rows only) |
~17 | admin-regression | gercek1/migrate-social-events-readonly |
Wave 2 — Admin mutation (92 tests, 6 batches)¶
Mutates admin-side records (contacts, members, tags, pages, posts, jobs). Each batch must define unique run prefix + cleanup. Run against gercek.raklet.org (or .raklet.net after cleanup approval).
| Batch | Feature area | Approx tests | Target suite | Branch name |
|---|---|---|---|---|
| AM-1 | Raklet.UI.Test.1/ContactTests (mutation rows) |
~14 | admin-regression | gercek1/migrate-contacts-mutation |
| AM-2 | Raklet.UI.Test.1/ApplicationFormTests (admin mutation rows only) |
~5 | admin-regression | gercek1/migrate-applicationform-admin |
| AM-3 | Raklet.UI.Test.3/SettingsTests (mutation rows) |
~25 | admin-regression | gercek1/migrate-settings-mutation |
| AM-4 | Raklet.UI.Test.4/SocialTests (mutation rows) |
~30 | admin-regression | gercek1/migrate-social-mutation |
| AM-5 | Raklet.UI.Test.5/EventsTests (admin mutation rows only) |
~15 | admin-regression | gercek1/migrate-events-admin |
| AM-6 | Raklet.UI.Test.4/JobsTests + Raklet.UI.Test.2/MessageModuleTests + Raklet.UI.Test.2/DirectoryTests |
~25 | admin-regression | gercek1/migrate-jobs-messages-mutation |
Wave 3 — Payment mutation (113 tests, 5 batches)¶
Requires Stripe/Iyzico sandbox fixtures. Run on .raklet.net only when sandbox env vars are set. Tests skip cleanly when fixtures are missing.
| Batch | Feature area | Approx tests | Target suite | Branch name |
|---|---|---|---|---|
| PM-1 | Raklet.UI.Test.1/ApplicationFormTests (payment rows) |
~11 | payment-regression | gercek1/migrate-applicationform-payment |
| PM-2 | Raklet.UI.Test.1/BillingTests + Raklet.UI.Test.1/ContactTests (payment rows) |
~12 | payment-regression | gercek1/migrate-billing-contact-payment |
| PM-3 | Raklet.UI.Test.2/FundraisingTests |
~22 | payment-regression | gercek1/migrate-fundraising-payment |
| PM-4 | Raklet.UI.Test.5/EventsTests (payment rows) |
~29 | payment-regression | gercek1/migrate-events-payment |
| PM-5 | Raklet.UI.Test.5/MembershipTests |
~27 | payment-regression | gercek1/migrate-membership-payment |
Wave 4 — Email regression (16 tests, 1 batch)¶
Mailbox ownership required. Not a default PR blocker.
| Batch | Feature area | Approx tests | Target suite | Branch name |
|---|---|---|---|---|
| EM-1 | Raklet.UI.Test.5/OutlookEmailTests + Raklet.UI.Test.5/OnboardingTests + email rows |
~16 | email-regression (new suite) | gercek1/migrate-email-regression |
Parallelization rules¶
- No two agents on the same feature folder. Batch boundaries are folder boundaries.
- Wave 1 can run fully in parallel. Wave 2 also fully parallel. Wave 3 needs payment fixtures wired up first (single env-var setup PR before this wave).
- Conflict surface: the only shared file all batches touch is browser-test-migration-checklist.md (rows get checked off). PR merges resolve naturally; if collisions happen they are textual and small.
- Each batch = 1 PR. No branch-of-branch stacking unless an agent explicitly coordinates with another's work.
- Acceptance per batch: runner exits 0 against
gercek.raklet.orgfor admin-regression batches; runner exits 0 or skips cleanly for payment-regression batches when sandbox fixtures aren't set.
Suggested agent assignment¶
These are just defaults — adjust as you have agent capacity.
| Agent | Suggested batches | Rationale |
|---|---|---|
| Claude (this session) | RO-1, AM-1 | Has full context; good for the first batch in each wave to validate the prompt. |
| Codex CLI | RO-3, RO-4, AM-3, AM-4, PM-3, PM-4 | Headless; good for grinding through high-count batches. |
| Cursor | RO-2, AM-2, AM-5, AM-6, PM-1, PM-2 | Interactive; better for batches with selector ambiguity or where decisions are needed. |
| Reserve | PM-5, EM-1 | Membership billing and email need extra sandbox setup; do last. |
How to run a batch¶
The reusable system prompt is browser-test-migration-prompt.md. Each agent gets:
- The system prompt verbatim.
- A 3-line task brief:
Batch ID,Feature folder,Branch name.
Example brief:
Batch AM-1. Feature folder:
Raklet.UI.Test.1/ContactTests(mutation rows in the checklist). Branch:gercek1/migrate-contacts-mutation.
That is enough — the system prompt tells the agent how to find rows, write tests, run them, and open the PR.