ActionEditor Refactor – Test Baseline & Guardrails

Existing Automated Coverage

• Covers UI 1-based → backend 0-based index translation, option selections, and fallback behavior when no options are provided.
• Verifies filterVariants/matchesVariantFilter integration (variant DSL + selection modes).
• tests/bulkNew.action.test.ts
  • Ensures bulk-new form submissions serialize actions + DSL correctly, validates limit normalization, and checks usage-cap redirects.
  • Confirms converters are invoked for every action prior to job creation (critical when reshaping ActionConfig).
• tests/bulkNew.loader.test.ts
  • Verifies saved filters/templates load and initial query params are parsed.
• tests/bulkEditPreview.test.ts & tests/preview.test.ts
  • Cover preview generation logic fed by the same action configs, indirectly guarding regression when refactoring config structures.
• Playwright suites (tests/bulk-tasks/*.pw.spec.ts, tests/bulk-variants/*.pw.spec.ts, tests/non-bulk/*.pw.spec.ts)
  • Exercise the full ActionEditor UI: adding actions, interacting with dropdowns/inputs, invoking Create/Preview/Save task controls, and walking through variant-heavy flows.
  • Validate critical UX paths like adding variant-dependent actions (SKU/barcode), running preview/create/duplicate, and ensuring CSV/usage experiences still work.

Behaviors to Preserve (Refactor Guardrails)

1. Card badges and validity:
   • Ready vs. Needs input vs. Not configured must remain accurate for every action type.
   • Validation error messaging (e.g., “Enter a SKU value”, “Namespace required”) should not change without intent.
2. Variant targeting semantics:
   • UI remains 1-based for “Variant number”, mapped to 0-based runner logic.
   • By option requires at least one option field to persist; All / First / Last remain defaults.
   • variantTargetingSummary strings drive the inline “Variants to edit” sentence and should stay human-readable.
3. Pattern helpers:
   • Pattern pickers (PATTERN_VARIABLES) for tags/title/sku/barcode/metafield components keep current behavior and tooltips.
   • patternSequentialBase shared handling must remain consistent.
4. Special affordances:
   • “Add rule for blank SKUs” button injects the correct DSL rule and expands the variant filter area.
   • Collapsible state per action card (“Edit”/“Collapse”) and “Change variants to edit” toggle text remain meaningful.
5. Action summaries & ordering controls:
   • actionSummary text displayed beside each badge stays stable.
   • Move/Duplicate/Remove buttons keep working with newly factored child components.

New Tests to Add Before/While Refactoring

1. Helper unit tests (Vitest)
   • validateAction for all action types covering happy-path + error states.
   • isActionActive for edge cases (pattern usage, variantAdd empty config, variantDelete selection-only).
2. Component tests
   • ActionEditor smoke test to assert badge states, variant summary copy, and variant interactions update ActionConfig.
   • New VariantFilterAndSelection component tests once extracted (selection mode switches, saved group load/save contract).
3. Extended E2E scenarios
   • Variant-specific flows: set SKU for first matching variant, price change by option filter
   • Regression case for “Add rule for blank SKUs” and verifying summary text updates accordingly.

This baseline will guide incremental refactors (validation helpers, shared components) while ensuring automated tests cover the behaviors most likely to regress.