What is Magento MFTF?

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.

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 (vendor/bin/mftf 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.

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 /Test/Mftf/Helper/*.php 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.

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.

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.

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.