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

Migrating an existing Cypress or Selenium E2E suite into Fume is usually more about mapping your current test intent and flows than rewriting everything from scratch. The key is to translate what you already test—user journeys, assertions, environments, and CI setup—into Fume’s model-based, AI-assisted automation approach.

Below is a step‑by‑step look at the typical migration process, what to plan for, and how to avoid common pitfalls, specifically for teams moving from Cypress or Selenium to Fume.

1. Clarify your migration goals and scope

Before touching any code, decide what “success” looks like for your Fume migration:

Do you want to reduce flaky tests?
Do you want faster test creation and maintenance?
Do you want broader coverage of critical user journeys?

Then scope the migration:

Start with a pilot set of tests
Pick:
- High-value, business-critical flows (checkout, signup, login, onboarding)
- Representative complexity (forms, API-driven content, authentication, etc.)
- Test cases that are currently flaky or costly to maintain
Define a timeline and rollout plan
- Phase 1: Pilot flows in Fume, run in parallel with Cypress/Selenium
- Phase 2: Expand coverage; refine test modeling
- Phase 3: Decommission duplicate E2E tests in Cypress/Selenium once confidence is high

This keeps risk low and gives you measurable, incremental wins.

2. Audit and categorize your existing E2E suite

A structured audit of your Cypress or Selenium tests helps you plan what to migrate and what to retire.

2.1. Group tests by value and complexity

Categorize your suite into:

Critical paths
- Payment and checkout
- Login, signup, password reset
- Core product workflows
Supporting flows
- Settings, profile, preferences
- Non-critical forms and wizards
Low-value or redundant tests
- Overlapping coverage with backend tests
- Purely visual checks already covered by other tools

Prioritize migrating critical paths first; some low-value tests may be better to delete than port.

2.2. Identify cross-cutting concerns

From your Cypress or Selenium codebase, list:

Common setup/teardown patterns
e.g., seeding test data, resetting DB, using feature flags or fixtures
Shared helpers and utilities
e.g., login helpers, API wrappers, test user creation
Environment usage
- Dev, staging, production-like
- Config differences, feature flags, or test accounts
Flaky areas
- Tests with heavy use of cy.wait(), thread.sleep(), or brittle CSS selectors
- Tests failing due to timing, dynamic content, or animations

These insights feed directly into how you model tests and environments in Fume.

3. Map Cypress/Selenium concepts to Fume

Fume is more model-oriented and intent-driven, so you won’t simply copy/paste test code. Instead, you translate key concepts:

3.1. From test scripts to user journeys

Cypress/Selenium: step-by-step instructions (click this, type that, wait, assert)
Fume: declarative user journeys that describe:
- Starting point (URL, user state)
- High-level steps (e.g., “log in as X”, “add item to cart”, “complete checkout”)
- Expected outcomes (what must be true at the end)

Your existing test names, descriptions, and comments often map directly to these journeys.

3.2. From DOM selectors to application models

Cypress/Selenium: heavy use of selectors (data-testid, #id, .class)
Fume: more resilient screen / component models that abstract the UI structure

Start by:

Listing key pages and components you use frequently (login, navbar, product card, modal)
Mapping repetitive selector usage to Fume’s equivalent reusable components or model elements

This is one of the biggest maintainability gains when leaving traditional E2E scripting.

4. Set up Fume and connect to your environments

Before migrating specific tests, make sure Fume is properly connected.

4.1. Configure projects and environments

In Fume:

Create a project for your application
Add environments:
- staging (often the primary E2E target)
- dev or qa (optional, if you run tests earlier in the pipeline)
- production-like environment if you do smoke tests

For each environment, configure:

Base URL
Environment variables or secrets (API keys, auth, feature flags)
Test users or service accounts, if needed

4.2. Integrate authentication and test data

If your Cypress/Selenium suite already handles auth and fixtures:

Replicate or improve this in Fume:
- Use API calls or short-circuited auth endpoints where available
- Create test users with deterministic states (e.g., “user with full cart”, “new user”)
Decide which flows are tested:
- From login onward
- Or end-to-end from signup to main workflow

Fume tests should reflect your real-world login/auth strategies without needing brittle front-end-only hacks.

5. Recreate core flows in Fume, guided by existing tests

Now you start translating your Cypress or Selenium tests into Fume journeys.

5.1. Start with one representative flow

Pick one well-understood test, for example: “Guest user checks out with credit card”.

In Cypress/Selenium, this might involve:

Visiting /
Searching or selecting a product
Adding to cart
Opening the cart
Filling checkout form
Submitting and verifying confirmation

In Fume, you’d:

Define the journey (Given/When/Then style):
- Given a guest user on the homepage
- When they add a product to the cart and complete the checkout form
- Then they see an order confirmation with a valid order ID
Model the screens/components:
- Product listing / search
- Product detail
- Cart
- Checkout form
- Confirmation page
Add assertions:
- URL or route
- Key text, messages, and order summary
- Critical UI elements (e.g., “Thank you” message, order number)

Use your existing test as a reference for expected data and edge cases.

5.2. Replace low-level waits with resilient synchronization

Cypress/Selenium tests often rely on:

cy.wait(2000)
await driver.sleep(1000)
Explicit waits on hard-coded timeouts

In Fume, rely on:

Smart waits for elements or states
Built-in synchronization with network or DOM changes
High-level “ready” conditions (e.g., page loaded, component visible)

This dramatically reduces flakiness as you migrate.

6. Validate parity between Fume and your existing suite

Once a few flows are in Fume, verify they match the behavior and coverage of your old tests.

6.1. Run tests in parallel for a period

Continue running Cypress/Selenium in CI while:
- Running the equivalent flows in Fume
Compare:
- Pass/fail rates
- Flakiness
- Execution times
- Error types or failure modes

This parallel period builds trust in Fume before you sunset your old E2E suite.

6.2. Refine and expand coverage

Using the insights from parallel runs:

Add or refine:
- Edge cases you previously scripted (e.g., invalid input, network errors)
- Important regression scenarios
Remove redundant legacy tests:
- If Fume now fully covers a flow more robustly, you can remove overlapping Cypress/Selenium tests to reduce maintenance.

7. Connect Fume to your CI/CD pipeline

To fully replace Cypress or Selenium, Fume must integrate with your delivery workflow.

7.1. Replace E2E stages in your pipeline

Wherever you currently run Cypress or Selenium (e.g., GitHub Actions, GitLab CI, CircleCI, Jenkins):

Add Fume’s CLI or integration
Configure:
- Which journeys to run on each pipeline (smoke vs full regression)
- Environment selection (e.g., staging vs preview URLs)
- Triggers (PRs, nightly builds, pre-release gates)

You’ll typically:

Run targeted smoke suites on pull requests
Run broader regression suites nightly or before release

7.2. Wire up reporting and notifications

Ensure your team can see and act on Fume test results:

Publish reports or dashboards
Connect notifications to Slack, email, or your incident channel
Define failure triage rules:
- Who investigates failures in Fume?
- What’s the process to mark known issues or update tests when the UI changes?

8. Handle advanced patterns and special cases

Many mature Cypress or Selenium suites use advanced techniques. Here’s how they typically map when migrating into Fume.

8.1. Data seeding and fixtures

If you rely on:

Database seeds
REST/GraphQL fixtures
Mock servers

Consider:

Reusing backend seeding scripts, just triggered as part of Fume test setup
Using environment-specific APIs to create test entities on demand
Keeping fixture data small and specific to each journey

The goal: deterministic states without over-coupling to low-level implementation details.

8.2. Third-party integrations and payments

Your existing tests might stub payment providers or external services. In Fume:

Use sandbox/test modes where possible (Stripe test cards, OAuth sandbox accounts)
Abstract external steps through:
- “Pay with card” or “Complete OAuth login” journeys
- Environment-level configuration for third-party credentials

Avoid full mocking that invalidates the real UX; aim for safe-but-realistic integration testing.

8.3. Cross-browser or device coverage

If your Selenium suite covers multiple browsers:

Configure Fume to target the browsers/devices you care about
Start with your primary browser (often Chrome) and expand coverage once stable
Use Fume’s reporting to spot browser-specific issues rather than creating separate, duplicated test logic

9. Decommission Cypress/Selenium in a controlled way

Once your Fume suite is stable and integrated, you can gradually retire your old E2E tests.

9.1. Use a migration matrix

Maintain a simple mapping:

Legacy Test ID / file
Fume Journey / suite
Status:
- Not started
- In progress
- Validated
- Decommissioned

Only mark a legacy test as “safe to delete” when:

The corresponding flow is fully covered and passing in Fume
The CI pipeline uses Fume instead of the old test for gating merges/releases

9.2. Clean up dependencies and tooling

As you remove legacy tests:

Remove unused:
- Cypress or Selenium config files
- Test-only helpers and wrapper utilities
- Outdated CI steps and scripts
Update internal docs:
- Onboarding guides
- “How we test” documentation
- Contribution guidelines for adding new tests (now in Fume)

This avoids confusion for new team members and reduces long-term maintenance costs.

10. Best practices for a smooth Cypress/Selenium → Fume migration

To keep the migration efficient and low-risk:

Do not mirror everything 1:1
Use the migration as a chance to:
- Remove redundant tests
- Focus on business-critical journeys
- Simplify flakiness-prone patterns
Think in flows, not selectors
Describe real user behavior and outcomes; let Fume handle the low-level details.
Start small and iterate
A handful of core journeys can deliver immediate value while you still rely on the legacy suite.
Continuously review value
Ask regularly: “Does this test protect real user value?” If not, don’t migrate it.
Leverage Fume’s strengths
Use Fume’s model-based approach and smart synchronization to reduce the maintenance burden that grows with Cypress/Selenium scripts.

Summary of the migration process

For teams wondering what’s the process to migrate an existing Cypress or Selenium E2E suite into Fume, the high-level path looks like this:

Define goals and scope – Pick a pilot set of critical flows.
Audit existing tests – Classify by value, complexity, and flakiness.
Map concepts – Translate procedural scripts into Fume’s journeys and models.
Set up Fume and environments – Configure URLs, auth, and test data.
Rebuild key flows in Fume – Start with one representative journey and expand.
Run in parallel – Compare Fume against Cypress/Selenium for a transition period.
Integrate into CI/CD – Replace old E2E steps with Fume tests.
Handle advanced patterns – Data seeding, third-party integrations, and browsers.
Decommission gradually – Remove legacy tests once coverage and confidence exist.
Continuously refine – Keep improving flow modeling and test strategy over time.

By treating migration as a structured, phased project rather than a one-time rewrite, you can smoothly move from a brittle Cypress or Selenium E2E suite to Fume’s more resilient, maintainable testing approach without sacrificing coverage or shipping velocity.