Magento Testing: Test Types, MFTF, Tools, and Checklist

What Is Magento Testing?

Magento testing is the set of automated and manual checks that confirm a Magento store's code, APIs, storefront, and Admin work together before a release. Adobe publishes the platform in two editions, Adobe Commerce and Magento Open Source, and its testing documentation applies to both.

According to Adobe's released versions page, the latest release is 2.4.9, dated May 12, 2026, and security patch 2.4.8-p5 shipped the same day.

The platform's architecture decides where tests are needed most:

• Modules - a store is the sum of Magento's core modules, third-party extensions, and custom code, and each module can carry its own tests in Test/Unit, Test/Integration, and Test/Mftf directories.
• Storefront themes - the default Luma theme and the Hyvä theme render the same cart and checkout with different markup and JavaScript, so a browser test written for one can fail on the other.
• Patch releases - the same Adobe page lists four 2.4.8 security patches between August 2025 and May 2026, and each one calls for regression testing on staging before it reaches production.

Stores on other platforms need a different plan. The guides to WooCommerce testing and how to test Shopify stores cover those, and the list of eCommerce test cases applies to any storefront.

Types of Magento Tests

Magento's test suites live inside the codebase, so every project already has the tooling for each layer. Each row below comes from Adobe's testing documentation and the 2.4.9 source tree.

The bin/magento dev:tests:run command wraps the PHPUnit suites. Adobe's command-line reference lists its accepted types as all, unit, integration, integration-all, static, static-all, integrity, legacy, and default, so the JavaScript, Web API, and MFTF suites always run through their own commands.

The composer.json of Magento 2.4.9 requires PHPUnit ^12.0 and MFTF ^6.0 and supports PHP 8.3, 8.4, and 8.5. Check those constraints first when a CI image still carries an older PHP or PHPUnit.

Match the layer to the risk:

• Custom module logic - cover price rules, tax math, and data transforms with unit tests, which exercise one class at a time and need no browser.
• Plugins, observers, and database queries - use integration tests, which Adobe's integration testing guide says require the Commerce runtime environment and a database of their own.
• REST and GraphQL contracts - use Web API functional tests when a mobile app, a headless frontend, or an ERP depends on the response shape. The API testing guide covers the method.
• Checkout, payment, and Admin flows - use functional testing in a real browser, which the next two sections cover.

Austin Siewert

Co-Founder, Steadfast Systems

Discovered @TestMu AI yesterday. Best browser testing tool I've found for my use case. Great pricing model for the limited testing I do 👏

2M+ Devs and QAs rely on TestMu AI

Deliver immersive digital experiences with Next-Generation Mobile Apps and Cross Browser Testing Cloud

Sign up with googleSign up with Email

How Does the Magento Functional Testing Framework Work?

Adobe describes the Magento Functional Testing Framework (MFTF) as a framework for automated end-to-end functional testing of Adobe Commerce and Magento Open Source projects. You write tests as XML, MFTF generates PHP Codeception tests from them, and Codeception drives a browser through Selenium WebDriver, with results written in Allure format.

MFTF tests are Magento's acceptance tests: their configuration sits under dev/tests/acceptance, and they exercise the store the way a shopper or an Admin user would. The Magento_Checkout module alone has 137 entries in its Test/Mftf/Test directory at the 2.4.9 tag.

MFTF versions move with Magento releases: the composer.json of Magento 2.4.8-p5 requires MFTF ^5.0, 2.4.9 requires ^6.0, and the 2.4-develop branch already requires ^7.0. Run vendor/bin/mftf --version to see which version a project has installed, and treat the composer.json of your release as the reference.

The MFTF repository published release 7.0.0 on August 14, 2026.

Adobe's MFTF getting-started guide has not caught up: it still states that the latest 2.4.x releases support Functional Testing Framework 3.x.

Anatomy of an MFTF Test

This is AdminLoginSuccessfulTest from the Magento_Backend module in the 2.4.9 source, with the license header removed:

<?xml version="1.0" encoding="UTF-8"?>
<tests xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="urn:magento:mftf:Test/etc/testSchema.xsd">
    <test name="AdminLoginSuccessfulTest">
        <annotations>
            <features value="Backend"/>
            <stories value="Login on the Admin Login page"/>
            <title value="Admin should be able to log into the Magento Admin backend successfully"/>
            <description value="Admin should be able to log into the Magento Admin backend successfully"/>
            <severity value="CRITICAL"/>
            <testCaseId value="MAGETWO-71572"/>
            <group value="example"/>
            <group value="login"/>
            <group value="cloud"/>
        </annotations>
        <actionGroup ref="AdminLoginActionGroup" stepKey="loginAsAdmin"/>
        <actionGroup ref="AssertAdminSuccessLoginActionGroup" stepKey="assertLoggedIn"/>
        <actionGroup ref="AdminLogoutActionGroup" stepKey="logoutFromAdmin"/>
    </test>
</tests>

The annotations block feeds the Allure report, and the group values let run:group select tests. The three steps are action groups, reusable step sequences stored in the module's Test/Mftf/ActionGroup directory.

The same Test/Mftf directory holds Section files for selectors, Page files for URLs, and Data files for test data. Because steps reference sections instead of raw selectors, one selector change repairs every test that uses it.

How to Set Up and Run MFTF

Adobe's getting-started guide lists the prerequisites: a PHP version your Magento release supports, Composer, Java, and a Selenium server with ChromeDriver. The sequence below condenses that guide and the MFTF command reference:

# 1. Apply the store settings Adobe's guide requires before the first run
bin/magento config:set cms/wysiwyg/enabled disabled
bin/magento config:set admin/security/admin_account_sharing 1
bin/magento config:set admin/security/use_form_key 0
bin/magento cache:clean config full_page

# 2. Build the Codeception project, then set MAGENTO_BASE_URL, MAGENTO_BACKEND_NAME,
#    and MAGENTO_ADMIN_USERNAME in dev/tests/acceptance/.env
vendor/bin/mftf build:project

# 3. Let MFTF run bin/magento commands through the web server
cp dev/tests/acceptance/.htaccess.sample dev/tests/acceptance/.htaccess

# 4. With a Selenium server running, diagnose the setup and run one test
vendor/bin/mftf doctor
vendor/bin/mftf run:test AdminLoginSuccessfulTest --remove

# 5. Run every test in the "login" group, then open the Allure report
vendor/bin/mftf run:group --remove login
allure serve dev/tests/acceptance/tests/_output/allure-results/

Adobe's documentation attaches these constraints to the sequence:

• WYSIWYG - Adobe's guide states that a Selenium web driver cannot enter data into fields with WYSIWYG, so the editor is disabled for test runs.
• Admin security - the guide requires Admin Account Sharing to be enabled and Add Secret Key to URLs to be disabled before tests run.
• Web server root - the guide notes that MFTF cannot execute CLI commands when the web server points at the pub directory, so point it at the Magento root on the test instance.
• Credentials - the store URL, Admin path, and Admin username go in dev/tests/acceptance/.env, while the guide keeps the Admin password in MFTF's credentials file.
• doctor - the command reference describes vendor/bin/mftf doctor as a check of Admin credentials, Selenium availability, and browser access, which makes it the fastest way to find a broken setup.

These commands are quoted from Adobe's documentation and were not executed for this guide, because MFTF needs an installed Magento instance with Admin access. Run them on a development or staging store only: Magento's own StorefrontGuestCheckoutTest, for example, creates a category and a product before it runs and deletes them afterwards.

MFTF Waits and Limits

MFTF builds Magento's asynchronous page behavior into its WebDriver module. In the 7.0.0 source, waitForPageLoad waits for document.readyState to be complete, then for jQuery's active AJAX count to reach zero, then for a list of known loading masks to disappear.

Magento's storefront action groups add element-level waits on top. StorefrontAddToCartCustomOptionsProductPageActionGroup waits until #product-addtocart-button[disabled] is no longer visible before it clicks, a wait that the measurements later in this guide explain.

The limits come from the same design. Magento's storefront sections are written against Luma markup: CheckoutCartProductSection, for example, locates cart rows with //main//table[@id='shopping-cart-table']//tbody//tr. MFTF's default suite configuration also sets browser: 'chrome', so a store on another theme, or a team that needs Firefox and Safari coverage, needs a second browser layer.

MFTF reads its Selenium endpoint from SELENIUM_HOST, SELENIUM_PORT, SELENIUM_PROTOCOL, and SELENIUM_PATH in the .env file, so the generated Codeception tests can target an online Selenium Grid instead of a local server. TestMu AI documents the matching WebDriver settings in its guide to running Codeception tests on its grid.

How to Automate Magento Storefront Tests Across Browsers

A Magento storefront is a web application, so any browser automation tool can test it. The spec in this section uses Playwright because one test file runs on Chromium, Firefox, and WebKit, and it targets two public demo stores so the same flow meets two different themes.

demo.mage-os.org runs the Luma theme on Mage-OS, a community-run distribution built on Magento Open Source. demo.hyva.io runs Hyvä, a theme whose documentation lists Alpine.js and Tailwind CSS as its stack. The Luma practice store that many tutorials point to, magento.softwaretestingboard.com, returned HTTP 526 when checked on October 1, 2026.

Every run stops at the checkout page as a guest. The tests create a cart and never place an order, which is the limit to respect on a store you do not own.

Luma vs Hyvä Markup Differences

The flow is identical on both stores: open a product, add it to the cart, open the cart, start checkout. The markup behind each step, read from the live pages in Chrome, differs:

Role-based locators absorb most of this. The Add to Cart button, the alert, and the email field have the same accessible role and name on both themes, while the cart count, the checkout control, and the checkout layout need theme-specific handling.

Playwright Spec for Both Themes

The spec loops over the two stores and uses only locators that hold on both:

import { test, expect } from '../lambdatest-setup.js'

const stores = [
  {
    theme: 'Luma',
    product: 'https://demo.mage-os.org/fusion-backpack.html',
    cart: 'https://demo.mage-os.org/checkout/cart/',
    checkout: 'https://demo.mage-os.org/checkout/',
    name: 'Fusion Backpack',
  },
  {
    theme: 'Hyva',
    product: 'https://demo.hyva.io/default/roka-glass-vase.html',
    cart: 'https://demo.hyva.io/default/checkout/cart/',
    checkout: 'https://demo.hyva.io/default/checkout/',
    name: 'Röka Glass Vase',
  },
]

for (const store of stores) {
  test(store.theme + ': guest adds a product to the cart and reaches checkout', async ({ page }) => {
    await page.goto(store.product)
    await expect(page.getByRole('heading', { level: 1 })).toHaveText(store.name)

    // Luma renders this button disabled and enables it from JavaScript after the load event.
    const addToCart = page.getByRole('button', { name: 'Add to Cart' })
    await expect(addToCart).toBeEnabled()
    await addToCart.click()

    // Both themes fill a role="alert" region from JavaScript once the cart request returns.
    await expect(page.getByRole('alert').filter({ hasText: 'You added ' + store.name })).toBeVisible()

    // The cart is a <table> in Luma and a <fieldset> in Hyva, but the id is the same.
    await page.goto(store.cart)
    await expect(page.locator('#shopping-cart-table')).toContainText(store.name)

    // Scope to <main>: the Hyva footer has a newsletter field with the same accessible name.
    await page.goto(store.checkout)
    await expect(page.getByRole('main').getByRole('textbox', { name: /email address/i })).toBeVisible()
  })
}

The lambdatest-setup.js fixture is a JavaScript port of the cloud fixture in TestMu AI's Playwright skill. Projects whose name ends in @lambdatest connect to a cloud browser at wss://cdp.lambdatest.com/playwright, other projects launch a local browser, and each cloud session reports its pass or fail status to the dashboard:

import { test as base, chromium } from '@playwright/test'
import { execSync } from 'node:child_process'

const pwVersion = execSync('npx playwright --version').toString().trim().split(' ')[1]

export const test = base.extend({
  page: async ({}, use, testInfo) => {
    const projectName = testInfo.project.name

    if (projectName.includes('@lambdatest')) {
      const [browserName, browserVersion, platform] = projectName.split('@lambdatest')[0].split(':')
      const capabilities = {
        browserName,
        browserVersion,
        'LT:Options': {
          platform,
          build: 'Magento storefront - Luma and Hyva',
          name: testInfo.title,
          user: process.env.LT_USERNAME,
          accessKey: process.env.LT_ACCESS_KEY,
          network: true,
          video: true,
          console: true,
          playwrightClientVersion: pwVersion,
        },
      }

      const browser = await chromium.connect({
        wsEndpoint: 'wss://cdp.lambdatest.com/playwright?capabilities=' + encodeURIComponent(JSON.stringify(capabilities)),
      })
      const context = await browser.newContext(testInfo.project.use)
      const ltPage = await context.newPage()

      await use(ltPage)

      const status = testInfo.status === 'passed' ? 'passed' : 'failed'
      const remark = testInfo.error?.message || 'OK'
      await ltPage.evaluate(
        () => {},
        'lambdatest_action: ' + JSON.stringify({ action: 'setTestStatus', arguments: { status, remark } }),
      )
      await ltPage.close()
      await context.close()
      await browser.close()
    } else {
      const browser = await chromium.launch()
      const context = await browser.newContext()
      const page = await context.newPage()
      await use(page)
      await context.close()
      await browser.close()
    }
  },
})

export { expect } from '@playwright/test'

Each project name encodes the browser, version, and platform that the fixture parses:

import { defineConfig } from '@playwright/test'

export default defineConfig({
  testDir: './tests',
  timeout: 120 * 1000,
  expect: { timeout: 30 * 1000 },
  workers: 3,
  reporter: 'list',
  projects: [
    { name: 'chrome:latest:Windows 11@lambdatest' },
    { name: 'pw-firefox:latest:Windows 11@lambdatest' },
    { name: 'pw-webkit:latest:macOS Sequoia@lambdatest' },
  ],
})

Install Playwright without its local browsers, mark the project as an ES module so the .js files can use import, export your credentials, and run the suite:

PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 npm install -D @playwright/test
npm pkg set type=module
export LT_USERNAME=<your-username>
export LT_ACCESS_KEY=<your-access-key>
npx playwright test

Running 6 tests using 3 workers


  ok 2 [chrome:latest:Windows 11@lambdatest] › tests\storefront.spec.js:21:3 › Luma: guest adds a product to the cart and reaches checkout (31.1s)
  ok 3 [pw-firefox:latest:Windows 11@lambdatest] › tests\storefront.spec.js:21:3 › Luma: guest adds a product to the cart and reaches checkout (48.2s)
  ok 1 [pw-webkit:latest:macOS Sequoia@lambdatest] › tests\storefront.spec.js:21:3 › Luma: guest adds a product to the cart and reaches checkout (48.9s)
  ok 4 [chrome:latest:Windows 11@lambdatest] › tests\storefront.spec.js:21:3 › Hyva: guest adds a product to the cart and reaches checkout (28.8s)
  ok 6 [pw-webkit:latest:macOS Sequoia@lambdatest] › tests\storefront.spec.js:21:3 › Hyva: guest adds a product to the cart and reaches checkout (40.6s)
  ok 5 [pw-firefox:latest:Windows 11@lambdatest] › tests\storefront.spec.js:21:3 › Hyva: guest adds a product to the cart and reaches checkout (44.1s)

  6 passed (1.6m)

All six tests passed in 1.6 minutes: both themes on Chrome 154, Firefox 155, and WebKit 26.6, the versions the grid resolved latest to that day. No browser and no Selenium server ran on the local machine.

To start from an existing suite instead, elgentos publishes an open-source Playwright suite for Magento 2 on GitHub. Its README says the suite is designed for the Hyvä theme and checkout and warns against running it on a production site, because some tests write to the database.

The Disabled Add to Cart Button on Luma

Luma's product template renders the Add to Cart button with a disabled attribute, and the catalogAddToCart widget removes the attribute once RequireJS has loaded and initialized it. Both halves are in the 2.4.9 source: addtocart.phtml in Magento_Catalog and the _create() method of catalog-add-to-cart.js.

To measure the gap, a script loaded the Luma product page five times per browser, each time in a fresh browser context, and recorded when the load event fired and when the attribute was removed:

On the Hyvä store the button was enabled as soon as it was parsed, before the load event, in all 15 loads. On Luma, a test that clicks the moment navigation returns is clicking a disabled button. Each tool handles that differently:

• Playwright click() - Playwright's actionability checks make click() wait until the element is visible, stable, able to receive events, and enabled.
• toBeEnabled() - the spec above would pass without this assertion, because the click waits anyway. The assertion names the dependency and fails with a clear message if the widget never initializes.
• Forced clicks - in three runs, click({ force: true }) sent straight after the load event threw no error, showed no success message within eight seconds, and left the cart counter empty.
• Selenium click() - in six fresh Selenium 4.50 sessions on Chrome, isEnabled() returned false straight after get() under both the normal and the eager page load strategy. Every click still landed, because it reached the browser 0.7 to 1.1 seconds later over the remote connection.
• MFTF - Magento's own add-to-cart action group waits for the disabled state to clear before it clicks, as shown in the MFTF section.

A local Selenium server answers faster than a remote one, so do not rely on that delay. Wait for the enabled state explicitly:

const button = await driver.findElement(By.id('product-addtocart-button'));
await driver.wait(until.elementIsEnabled(button), 15000);
await button.click();

The cart count needs the same care. Adobe's private content documentation explains that per-shopper data such as the cart is loaded by JavaScript after the cached page arrives, and on the Luma store the .counter-number element was empty in the server HTML. Assert on the cart only after the success alert appears, and treat fixed sleeps as a source of flaky tests.

Each of the six sessions ran on TestMu AI's Automation Cloud, a hosted grid that runs existing Playwright, Selenium, and Cypress suites in parallel across 3,000+ browser and OS combinations. Because the fixture sets network, video, and console, every session keeps its network log, video, and console log, which is the evidence you need when checkout fails in WebKit and passes everywhere else.

A staging store behind a firewall is reachable through the TestMu AI Tunnel, and the same grid offers virtual Android and iOS browsers for the mobile checkout.

Note: Run your Magento storefront suite on Chrome, Firefox, and WebKit without maintaining a Selenium grid. Try TestMu AI free

How to Load Test a Magento Store

Functional tests show that one shopper can check out. Load testing shows what happens when many shoppers try at once, and Magento ships a data generator for it.

The performance toolkit lives in setup/performance-toolkit and fills a store with products, customers, and orders from a profile file. Adobe's guide to generating data for performance testing gives the command and defines the profiles:

bin/magento setup:perf:generate-fixtures /var/www/html/magento2/setup/performance-toolkit/profiles/ce/small.xml

Older tutorials tell you to run benchmark.jmx, a JMeter plan, from that directory. Checked against the repository's tags, the file is present in 2.4.5 and absent from 2.4.6 through 2.4.9, after a removal that GitHub dates August 1, 2022. Current versions need a plan you write yourself.

The removal is commit 6728063, which deleted benchmark.jmx and benchmark_2015.jmx from the magento2 repository.

Build that plan around these points:

• Scenarios - script the journeys the functional spec covers: category and product views, search, add to cart, and guest checkout, in the proportions your analytics show.
• Uncached requests - per Adobe's private content documentation, per-shopper data is fetched by JavaScript after the cached page loads, so a fast cached product page says little about add to cart and checkout. Weight the plan toward those requests.
• Data volume - generate the profile closest to your catalog size first, because a plan that passes against a small catalog can fail against a large one.
• Environment - run load tests only against an environment you own. No load test was run for this guide, because the demo stores belong to someone else.

Any HTTP load tool can drive a Magento store. JMeter fits teams that already maintain .jmx plans, including plans adapted from the old benchmark.jmx, and k6 and Gatling are code-first alternatives.

TestMu AI's HyperExecute runs an existing .jmx plan from its Projects dashboard: you upload the plan with its CSV data files, set total users, duration, and ramp-up time in a form, and read the results in the Summary, Timeline, Request Stats, Errors, and Logs reports. The JMeter load testing page describes the setup. Schedule the heaviest run before peak sales events, which the guide to Black Friday and Cyber Monday testing covers.

Magento Testing Checklist

Use this checklist before a release, an extension install, or a patch upgrade. Each row names the test layer that catches a failure in that area earliest, and the guide to writing effective test cases helps turn a row into steps.

For the Admin row, TestMu AI's Kane CLI use case for admin order creation runs the same kind of check on another commerce admin: create an order, then assert its status and sales channel. For the accessibility row, the guide to eCommerce accessibility testing goes deeper.

How Do AI Agents Test Magento Storefronts?

AI agents take on two jobs in Magento testing: writing tests from a description of the flow, and keeping those tests working when the markup changes.

KaneAI, TestMu AI's testing agent, takes a flow written in plain English, such as opening the Fusion Backpack page, adding it to the cart, and verifying that the cart lists it, and turns each line into an executable step. It finds elements by intent and context instead of a fixed selector, runs the test on the cloud grid, and can export it as Playwright, Selenium, or Cypress code.

That design suits the Luma and Hyvä differences above, since a step that says to verify the cart lists the product names neither a table nor a fieldset. When a theme update changes the page, KaneAI's self-healing re-anchors the affected step and surfaces the change for a reviewer to approve or reject. KaneAI was not part of the runs in this guide, which used Playwright and Selenium.

For Admin flows protected by two-factor authentication, KaneAI generates time-based one-time passwords from a secret key, so the login step behaves the same in replay and in CI.

Coding agents such as Claude Code can draft the PHPUnit and Playwright layers, and TestMu AI publishes open-source agent skills that give them framework patterns to follow. The PHPUnit, Codeception, and Playwright skills match a Magento codebase, and one command installs all three for Claude Code:

npx agentskillsforall add https://github.com/LambdaTest/agent-skills.git --skill phpunit-skill codeception-skill playwright-skill --agent claude-code -y --copy

The run ended with "Installed 3 skills" and copied each skill into .claude/skills. Drop --agent and -y to choose other agents, such as Cursor, from an interactive prompt.

Review agent-written Magento tests for these patterns before merging:

• Forced clicks - force: true on Add to Cart turns a timing problem into a silent no-op, as the three forced-click runs above showed.
• Fixed sleeps - a sleep long enough for Firefox on Luma, where the button took up to 4.1 seconds to enable, slows every other run. Wait for the enabled state instead.
• Theme-specific selectors - a locator such as #shopping-cart-table tbody tr passes on Luma and matches nothing on Hyvä.
• Cart assertions on server HTML - the cart count is filled in by JavaScript, so an assertion that runs before the success alert reads an empty counter.
• Orders on shared stores - a generated test that completes checkout places a real order. Stop before payment unless the store and the payment sandbox are yours.

Let Claude Code write Playwright tests for your Magento storefront that actually pass.

Install the Playwright Skill for FREE

Conclusion

Start by running ./vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist on your own modules, then add the storefront spec above to CI so every patch upgrade gets a browser run on Chrome, Firefox, and WebKit. To run that spec without a local grid, follow the guide to run Playwright tests on TestMu AI, and widen the browser matrix with TestMu AI's cross browser testing cloud.