What’s the process to migrate our Cypress or Selenium E2E suite into Fume?

Migrating your existing Cypress or Selenium E2E suite into Fume is a structured process that preserves your current test coverage while unlocking faster, more maintainable end‑to‑end testing. Instead of rewriting everything from scratch, you’ll gradually map your existing flows into Fume’s model‑based system, validate parity, and then phase out your legacy test runners.

Below is a step‑by‑step walkthrough of the typical migration process, what to expect at each stage, and how to keep your CI pipeline stable throughout.

1. Understand how Fume differs from Cypress and Selenium

Before migrating, it helps to understand the core differences:

Cypress / Selenium
- Code‑centric: tests are written in JavaScript/TypeScript (Cypress) or various languages (Selenium).
- DOM-targeted: selectors like cy.get('[data-cy="button"]') or driver.findElement(By.css('...')).
- Imperative flows: scripts describe step‑by‑step user actions and assertions.
Fume
- Model‑centric: you define reusable flows, screens, and actions rather than one-off scripts.
- Higher‑level abstractions: business actions (e.g., “log in”, “checkout”, “add item to cart”) become building blocks.
- Designed for scalability: easier maintenance, less selector flakiness, and more reliable regression coverage.

The migration process essentially means taking your current Cypress or Selenium flows and elevating them into these higher‑level Fume models while preserving behavior.

2. Plan your migration strategy and scope

Start by deciding what to migrate first and how quickly to transition:

2.1 Inventory your existing E2E tests

From your Cypress/Selenium suite, identify:

Critical user flows (e.g., sign‑up, login, checkout, subscription changes)
High‑value smoke tests (e.g., homepage load, navigation, major feature toggles)
Flaky or high‑maintenance tests (prime candidates for improvement with Fume)

Create a simple matrix:

Flow / Test Suite	Tool	Priority	Stability	Notes
User login & logout	Cypress	High	Stable	Core auth coverage
Checkout (guest & user)	Cypress	High	Flaky	Payment iframe & dynamic elements
Search & filter products	Selenium	Medium	Stable	Multiple browsers
Profile settings update	Cypress	Low	Flaky	Complex modals

Use this to choose an initial subset of high‑impact flows.

2.2 Choose a migration pattern

Most teams follow one of these approaches:

Parallel migration (recommended)
- Keep Cypress/Selenium running.
- Rebuild key flows in Fume.
- Run both in CI until Fume tests reach parity.
- Gradually deprecate legacy tests.
Incremental per‑feature migration
- When you touch a feature, recreate its tests in Fume.
- Phase out Cypress/Selenium tests for that feature after Fume coverage stabilizes.
Big‑bang migration (rare)
- Only for small suites or early-stage projects.
- Rewrite everything at once in Fume, then cut over.
- Riskier for mature systems.

For most production teams, parallel migration offers the best balance of safety and speed.

3. Set up Fume in your environment

Before migrating test logic, you need Fume connected to your app and CI.

3.1 Connect Fume to your application under test

Typical steps:

Configure environments
- Map your existing environments into Fume (dev, staging, pre‑prod, etc.).
- Align base URLs and environment variables.
Authentication setup
- If your Cypress/Selenium tests currently use API calls or cookies to bypass login, define equivalent approaches in Fume (e.g., login flow or token injection).
- For SSO or OAuth, you may build a dedicated Fume flow that handles the auth journey.
Network and data configuration
- Align test data strategies: seed data, fixtures, or mock APIs if applicable.
- Ensure Fume can reach the same endpoints your existing suites use.

3.2 Integrate Fume with your CI/CD pipeline

You’ll want Fume tests to run with the same discipline as your existing E2E suite.

Typical tasks:

Add a Fume test stage to your CI (GitHub Actions, GitLab CI, CircleCI, Jenkins, etc.).
Configure triggers:
- On pull requests / merge requests.
- On main branch merges.
- On nightly or scheduled runs.
Set thresholds:
- Decide whether failing Fume tests should block merges right away or only after a stabilization period.

During early migration, many teams run Fume tests in “report-only” mode (non-blocking) until confidence grows.

4. Map your existing Cypress or Selenium flows into Fume

With setup ready, you can start translating flows.

4.1 Identify reusable flows and actions

Take one high-priority Cypress or Selenium test and break it down into logical steps.

Example: a Cypress test for login and adding an item to cart:

// Pseudocode
cy.visit('/login');
cy.get('#email').type('user@example.com');
cy.get('#password').type('password123');
cy.get('button[type="submit"]').click();
cy.contains('Welcome, User');

cy.visit('/products');
cy.contains('My Cool Product').click();
cy.contains('Add to cart').click();
cy.get('.cart-badge').should('contain', '1');

In Fume, this becomes:

Flow: Login
- Action: open login page
- Action: enter email
- Action: enter password
- Action: submit and verify success
Flow: Add item to cart
- Action: open product listing
- Action: select product
- Action: add to cart
- Action: verify cart count

Once modeled separately, you can reuse these flows across multiple scenarios instead of duplicating steps like in many Cypress/Selenium suites.

4.2 Translate selectors and interactions

Instead of DOM‑focused calls like cy.get() or driver.findElement(), you’ll configure Fume to interact with elements at a more semantic level.

Migration tips:

Prefer stable attributes (e.g., data-testid) that mirror what your Cypress/Selenium tests already use.
Group related UI elements into Fume “screens” or equivalent abstractions so they can be reused.
Replace brittle CSS/XPath selectors with robust, maintainable identifiers as you migrate.

If your existing suite already uses good data-* attributes, this step is straightforward—often a 1:1 mapping.

4.3 Mirror assertions and validations

Take each assertion from your Cypress/Selenium tests and ensure it has a counterpart in Fume:

URL checks → page or state verification in Fume.
Text assertions → element content assertions.
Backend validations (e.g., verifying DB state) → either keep in existing helper scripts or move into Fume-integrated checks, depending on your architecture.

The goal is behavioral parity: the same user journey, the same expectations, just expressed in Fume.

5. Build your first Fume suite and validate parity

Once you’ve modeled a few flows, group them into suites that match your current E2E structure:

Smoke suite: basic health checks (login, main navigation, core page loads).
Checkout / payments suite: purchase flows, discounts, payment gateways.
Account management suite: profile update, password reset, billing changes.

5.1 Run Fume and legacy tests side-by-side

For each suite you replicate:

Run the existing Cypress/Selenium tests in CI.
Run the corresponding Fume suite on the same environment.
Compare:
- Pass/fail rate.
- Execution time and stability.
- Types of failures (environment vs. test logic vs. flakiness).

Document any gaps as you go:

Fume missed an assertion you had in Cypress/Selenium → add it.
The old test was flaky due to timing → use Fume’s more resilient waiting mechanisms.

5.2 Iterate to reach confidence

Expect a few rounds of refinement:

Adjust selectors or flows where your UI has changed since older tests were written.
Simplify flows: remove outdated, low‑value steps that no longer matter for regression.
Consolidate repetitive Cypress/Selenium logic into shared Fume actions.

Once Fume suites show consistent, reliable passes equivalent to or better than your legacy tests, you’re ready to start retiring old code.

6. Gradually deprecate Cypress or Selenium tests

Avoid keeping two parallel E2E stacks forever. As Fume coverage becomes robust:

6.1 Mark tests as “covered by Fume”

For each Cypress or Selenium test:

Confirm that a Fume flow or suite fully covers the same user journey and assertions.
Add a note or tag in your test code or test management system (e.g., @migrated-to-fume).
Track coverage in a simple migration checklist:

Flow / Test ID	Legacy Tool	Status	Fume Suite / Flow
login_basic	Cypress	Migrated	Auth / Login Flow
checkout_guest	Cypress	Migrated	Checkout / Guest Flow
profile_update_001	Selenium	In progress	Account / Profile Flow

6.2 Disable redundant tests in stages

To reduce risk:

First stage: skip or quarantine low‑value legacy tests once Fume coverage exists.
Second stage: remove the test files and references fully after an agreed stabilization window (e.g., 2–4 weeks).
Final stage: when most coverage is in Fume, decommission Cypress/Selenium from the CI pipeline.

This phased approach avoids sudden test coverage gaps while preventing long-term duplication and maintenance overhead.

7. Optimize your Fume suite for speed and maintainability

After migration, focus on using Fume’s strengths rather than mirroring old patterns.

7.1 Consolidate and deduplicate flows

Merge similar flows that ended up duplicated during migration.
Extract shared sequences (like login or setup steps) into reusable building blocks.
Ensure naming is consistent across flows and suites for clarity.

7.2 Improve reliability and reduce flakiness

Fume’s architecture should already reduce flakiness relative to raw Cypress/Selenium, but you can go further:

Use resilient wait strategies (e.g., wait for a meaningful state, not arbitrary timeouts).
Standardize how you handle dynamic elements, animations, and redirects.
Keep a tight feedback loop: treat any Fume flakiness as a top-priority issue until resolved.

7.3 Keep tests aligned with product changes

To avoid the drift common in Cypress/Selenium suites:

Update Fume flows as part of feature work (not as an afterthought).
Treat flows as product documentation as much as tests—ensure they match real user journeys.
Periodically review coverage to remove obsolete flows and keep the suite lean.

8. Common migration questions

Do we need to rewrite everything at once?

No. For most teams, it’s best to:

Start with a small set of critical flows.
Run Fume and Cypress/Selenium in parallel.
Gradually migrate remaining tests as you touch features or as old tests become painful to maintain.

Can we reuse our existing test data, hooks, and fixtures?

In many cases, yes:

If your Cypress/Selenium tests seed data via API or CLI scripts, those can usually be reused while Fume drives the UI.
Some before/after hooks can be mirrored with Fume’s setup/teardown mechanisms.
As you mature in Fume, you can formalize test data management there as well.

How long does a migration usually take?

It depends on:

Size of your Cypress/Selenium suite.
Complexity of flows (e.g., multi‑step wizards, third-party iframes).
Available engineering time.

Typical patterns:

Small apps: a few days to a couple of weeks.
Medium apps: a few weeks to 1–2 months, done incrementally.
Large enterprise systems: phased over a quarter or more, starting with high‑value smoke and regression suites.

9. Suggested phased migration roadmap

To make the process concrete, here’s a sample roadmap you can adapt:

Phase 1 – Foundation (Week 1–2)

Set up Fume for your main environments.
Integrate with CI in report‑only mode.
Model and implement 2–3 core flows (e.g., login, basic navigation, key landing pages).

Phase 2 – Critical flows (Week 3–6)

Migrate checkout, subscription, or other revenue‑critical flows.
Achieve parity with existing Cypress/Selenium smoke tests.
Start marking migrated tests in your legacy suite.

Phase 3 – Broad coverage (Week 7–12)

Expand to additional user journeys and edge cases.
Gradually disable overlapping Cypress/Selenium tests.
Make Fume suites required checks for main branch merges.

Phase 4 – Consolidation (Ongoing)

Remove remaining low-value or redundant legacy tests.
Refine Fume flows for performance and clarity.
Establish a standard pattern for adding new tests exclusively in Fume.

Migrating your Cypress or Selenium E2E suite into Fume is less about a massive rewrite and more about systematically lifting your existing flows into a more scalable model. By inventorying your current tests, modeling core journeys in Fume, validating parity, and then gradually deprecating old suites, you can improve stability and speed without sacrificing coverage or risking regressions.