Chat on WhatsApp
Toggle Nav
My Cart
Magento glossary

What is Magento MFTF ?

MFTF is the Magento Functional Testing Framework — Adobe’s official end-to-end (E2E) UI test runner for Magento 2 and Adobe Commerce. Tests are written declaratively in XML (no per-test PHP) and executed by Codeception, which drives Selenium / Chromedriver to control a real browser. Tests live in <Module>/Test/Mftf/*.xml. MFTF replaced the older Selenium suite around Magento 2.2 (2018) — Adobe runs ~12,000 MFTF tests per Magento release in CI, and MFTF is required for Marketplace EQP certification.

Need MFTF tests for your module? How it works

Written by Kishan Savaliya — Adobe Certified Magento & Hyvä developer, 8 years on platform

How it works

Five steps from first test XML to CI integration

MFTF isn't a black-box runner — it's a documented XML grammar plus Codeception under the hood. Here is the wiring, end to end.

  1. 01

    Write test XML in your module

    Drop a new test at <Vendor>/<Module>/Test/Mftf/Test/MyFeatureTest.xml. The XML declares <test> elements with annotations (stories, title, severity, group) and a list of test steps. No PHP class per test — the XML is the test. MFTF parses the XML at run time and generates a Codeception test on the fly.

  2. 02

    Reuse ActionGroups for common flows

    ActionGroups live under <Module>/Test/Mftf/ActionGroup/*.xml and are reusable test fragments — e.g. AdminLoginActionGroup logs into the admin, StorefrontAddProductToCartActionGroup adds a product. Reference them from tests with <actionGroup ref="AdminLoginActionGroup" stepKey="login"/>. This is how MFTF keeps a 12k-test suite maintainable.

  3. 03

    Pin selectors in Section files

    CSS / XPath selectors live in <Module>/Test/Mftf/Section/MySection.xml — completely separate from test logic. When Adobe rewrites the admin DOM in M2.4.7 you fix the selector in one Section file, not in 50 test files. Pin to data-test attributes where possible — they survive UI refreshes better than CSS class names.

  4. 04

    Run the test from the CLI

    Execute with vendor/bin/mftf run:test MyFeatureTest, or run a whole group with vendor/bin/mftf run:group myGroup. MFTF spins up Chromedriver, opens a real browser window (or runs headless with --headless), executes every step, and reports pass/fail. Run from your dev machine, your CI container, or a Selenium Grid worker — same XML, same result.

  5. 05

    Wire JUnit output into CI

    MFTF emits JUnit XML to dev/tests/acceptance/tests/_output/ plus screenshots + HTML page dumps on every failure. Plug those into Jenkins, GitHub Actions, GitLab CI, or Bitbucket Pipelines as test artefacts — Magento core uses this exact pattern on Adobe’s internal CI to run ~12,000+ MFTF tests per release. Failures show up as annotated build errors with screenshots inline.

When to use

Four situations where MFTF is the obvious answer

MFTF isn't the right tool for every Magento test scenario, but in 2026 these four situations are unambiguous wins.

  • Magento Marketplace EQP certification

    If you’re submitting a paid extension to the Magento Marketplace, MFTF tests are required for Extension Quality Program (EQP) certification. Adobe’s reviewers run your MFTF suite as part of the technical review — no MFTF means a failed submission. Bake at least one happy-path MFTF test per public-facing feature before you submit, and keep coverage above 60% to clear EQP comfortably.

  • Regression-testing custom modules across upgrades

    When Adobe ships Magento 2.4.6 → 2.4.7 your custom modules will silently break in three or four places — observer signatures change, admin form layouts move, GraphQL schemas drift. An MFTF suite running against the upgraded codebase catches those regressions in 10 minutes instead of three weeks of bug reports from production users. Run the suite on every composer update of magento/product-community-edition.

  • Large team / agency Magento builds

    On 5+ developer teams MFTF gives QA non-devs a way to write tests in declarative XML — no PHP knowledge, no Selenium API study. QA writes the test against the staging environment, devs review the XML in PR, the test joins the suite. PHPUnit unit tests stay with devs; MFTF E2E tests are shared with QA. This is how Adobe themselves split responsibility on the Magento core team.

  • Hardening pre-production releases

    Before pushing a major feature to production, run a smoke MFTF suite against staging that covers the critical paths: checkout, account creation, password reset, admin login, product save, order processing. Combine with PHPUnit for unit-level coverage. The two together (MFTF for E2E + PHPUnit for units) is the Adobe-recommended testing stack and gives the highest confidence before a Friday-night deploy.

Common mistakes

Three MFTF misconfigs that waste weeks of QA time

Almost every flaky-MFTF-suite I have been called in to fix came from one of these three mistakes. Audit your tests for them today.

  • Selectors pinned to unstable CSS classes

    The Magento admin DOM changes every minor version — .admin__data-grid-header in 2.4.5 becomes .admin-grid-header in 2.4.7, and your entire MFTF suite goes red. Pin selectors to data-test or data-mage-init attributes where they exist, fall back to semantic aria-label matches, and treat raw CSS classes as a last resort. Centralise them all in Section XML so a DOM rewrite is a one-file fix.

  • Running MFTF against production mode

    MFTF needs Magento in developer mode (or at least a fresh setup:static-content:deploy run) so the theme assets are compiled and the test runner can drive the rendered DOM. Running against a production-mode site without static-content deployed gives missing-asset 404s, broken layouts, and false-negative test failures. Run bin/magento deploy:mode:set developer on your CI Magento container before any MFTF run.

  • Mixing MFTF + PHPUnit + Cypress randomly

    Three E2E frameworks in one module is a maintenance nightmare — every selector lives in three places, every fixture is duplicated, every CI run takes 4× as long. Pick one E2E framework per module. MFTF is the Adobe-blessed choice and integrates with Magento Marketplace EQP automatically. PHPUnit stays for unit tests (different layer, different job). Drop Cypress / Playwright unless you have a non-Magento frontend layer that already uses it.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

FAQ

Magento MFTF — frequently asked questions

  • MFTF vs PHPUnit — what is the difference?
    They sit at different layers of the testing pyramid and solve different problems. PHPUnit is a unit-test framework — it instantiates a single PHP class in isolation, mocks its dependencies, and asserts behaviour at the method level. Tests are fast (milliseconds), deterministic, and run with the Magento application bootstrap but without a browser. MFTF is an end-to-end test framework — it drives a real Chromedriver browser against a running Magento install, clicks through real DOM elements, and asserts full-flow behaviour like "an admin can save a configurable product with three variants and the storefront then renders all three swatches." Tests are slow (~30 seconds each), realistic, and catch integration bugs PHPUnit can't see. Use both: PHPUnit for unit coverage, MFTF for E2E happy-path coverage.
  • MFTF vs Cypress or Playwright — why not those?
    Cypress and Playwright are excellent generic browser-test frameworks for any web app — fast, modern, good developer ergonomics. They are not Magento-aware. MFTF is Adobe-blessed, ships with Magento out of the box (<code>vendor/bin/mftf</code> is part of the magento/magento2-functional-testing-framework package), and integrates directly with Magento Marketplace EQP — your tests get re-run by Adobe’s reviewers when you submit an extension. MFTF also has built-in support for Magento entities (create a category fixture, create a customer fixture, create an order fixture) without you wiring up the data. For a Magento-only project pick MFTF. For a hybrid project (Magento backend + React storefront), Cypress / Playwright covers the React side and MFTF covers the Magento admin.
  • Can I write MFTF tests in PHP?
    No, by design — MFTF tests are XML only. The whole point is to make tests writable by QA non-developers and reviewable by anyone who can read XML. There are PHP escape hatches for cases the XML grammar can't express: Helper classes in <code><Module>/Test/Mftf/Helper/*.php</code> let you call arbitrary PHP from a test step (useful for setting up complex fixtures or hitting external APIs from a test), and Custom Actions let you extend the action vocabulary. Use them sparingly — every PHP escape hatch is a piece of test logic that lives outside the XML and breaks the "QA can read the test" promise. If you find yourself writing 200 lines of PHP per MFTF test, you probably want PHPUnit instead.
  • Does MFTF work on Hyvä storefronts?
    Yes, with one caveat. MFTF admin tests (which is the bulk of any test suite — order processing, product saves, customer admin, configuration changes) work identically on Hyvä sites because Hyvä only replaces the storefront theme, not the admin. MFTF storefront tests need updated Section selectors because Hyvä uses Alpine.js + Tailwind utility classes instead of KnockoutJS + RequireJS — the DOM structure is completely different. Most teams keep two storefront Section files: one for Luma, one for Hyvä, and switch via test groups. The Hyvä team also ships a hyva-themes/hyva-mftf companion package with pre-built Hyvä sections, which saves a few days of selector authoring.
  • How long does an MFTF suite take to run?
    Roughly 30 seconds per test as a working rule of thumb — that includes the browser cold start, Magento bootstrap, fixture creation, the test steps themselves, and screenshot/cleanup. The Magento core test suite at 12,000+ tests takes around 6 hours in Adobe’s CI, split across parallel Selenium Grid workers. For your own custom module, a focused 50-test smoke suite runs in 25 – 30 minutes single-threaded, or 5 – 8 minutes if you parallelise across 5 CI workers. Don't try to run the full suite on every PR — tag tests with severity groups (critical, normal, low) and run only critical on PR, full suite nightly. That keeps CI feedback fast without sacrificing coverage.
  • Can MFTF run against production?
    Strongly discouraged — MFTF tests create test products, place test orders, create test customers, and modify configuration as part of their setup. Running them against production means real customers see "MFTF Test Product 1234" in your catalogue, real orders get test-customer entries in your fulfilment queue, and real stock levels get decremented by checkout-flow tests. Always run MFTF against staging, CI, or a dedicated test environment that mirrors production but is isolated from real traffic. If you need to verify production behaviour after a deploy, use a small read-only smoke check (curl the storefront, hit the admin login page, check robots.txt) — not MFTF. MFTF is for environments you’re willing to write to.
MFTF audit

Want MFTF tests written for your Magento module?

Send your repo and feature list — I will scope an MFTF suite (critical happy paths, EQP-pass coverage, CI wiring) and reply with a written test plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get an MFTF quote Hire me directly