### Install Magento 2 Dependencies

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Navigates to the magento2 directory, checks out a specific version (e.g., 2.4-develop), and installs project dependencies using Composer. This prepares the Magento instance for testing.

```bash
cd magento2/
git checkout 2.4-develop
composer install
```

--------------------------------

### Clone and Start Code Server for Local Development

Source: https://github.com/adobedocs/commerce-testing/blob/main/README.md

Clones the adp-devsite repository, installs dependencies, and starts the code server for local development. This server is essential for the documentation website's frontend.

```bash
git clone https://github.com/AdobeDocs/adp-devsite
cd adp-devsite
npm install
npm run dev
```

--------------------------------

### Clone and Start Runtime Connector for Local Development

Source: https://github.com/adobedocs/commerce-testing/blob/main/README.md

Clones the devsite-runtime-connector repository, installs dependencies, and starts the runtime connector server. This component facilitates the connection between the content and code servers.

```bash
git clone https://github.com/aemsites/devsite-runtime-connector
cd devsite-runtime-connector
npm install
npm run dev
```

--------------------------------

### JavaScript Testing Setup and Run with Jasmine and Grunt

Source: https://context7.com/adobedocs/commerce-testing/llms.txt

This section details the setup and execution of JavaScript unit tests using Jasmine and Grunt. It includes commands for installing dependencies, deploying static content, and running tests for backend and frontend themes, as well as specific test files. Debugging can be enabled by configuring settings.json and accessing the SpecRunner HTML page.

```bash
# Prepare environment
npm install

# Generate static view files for testing
bin/magento setup:static-content:deploy -f

# Run all tests for backend theme
grunt spec:backend

# Run all tests for frontend theme
grunt spec:luma

# Run a single test file
grunt spec:backend --file="/path/to/the/test.js"

# Enable debugging mode
# Set keepalive: true in dev/tests/js/jasmine/spec_runner/settings.json
# Then visit http://localhost:8000/_SpecRunner.html
```

--------------------------------

### Setup Environment Variables for Commerce Testing

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/commands/mftf.md

Updates or creates the .env file with specified configuration parameters. Parameters are provided as key-value pairs. If a parameter does not exist, an error is returned. This command can also be used to create a .env file with example parameters from an example file.

```bash
vendor/bin/mftf setup:env [config_param_option1=<value>] [config_param_option2=<value>]
```

```bash
vendor/bin/mftf setup:env --MAGENTO_BASE_URL=http://magento.local/ --BROWSER=firefox
```

```bash
vendor/bin/mftf setup:env
```

--------------------------------

### Run Selenium Server

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

These commands download the Selenium Server Standalone JAR file and then run it. The Selenium server is required to execute browser-based functional tests. Ensure you have Java installed.

```bash
curl -O http://selenium-release.storage.googleapis.com/3.14/selenium-server-standalone-3.14.0.jar
java -Dwebdriver.chrome.driver=chromedriver -jar selenium-server-standalone-3.14.0.jar
```

--------------------------------

### Complex Fixture Composition Example (PHP)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/data-fixtures-guide.md

A complex example in PHP demonstrating fixture composition, including creating related fixtures, linking them using references, and passing arrays of data with references for inventory setup.

```php
use Magento\TestFramework\Fixture\DataFixtureStorageManager;

#[
    DataFixture(SourceFixture::class, ['source_code' => 'test_source'], 'source'),
    DataFixture(StockFixture::class, as: 'stock'),
    DataFixture(
        StockSourceLinksFixture::class,
        [['stock_id' => '$stock.stock_id$', 'source_code' => '$source.source_code$']]
    ),
    DataFixture(
        StockSalesChannelsFixture::class,
        ['stock_id' => '$stock.stock_id$', 'sales_channels' => ['base']]
    ),
    DataFixture(ProductFixture::class, as: 'p1'),
    DataFixture(ProductFixture::class, as: 'p2'),
    DataFixture(
        SourceItemsFixture::class,
        [
            ['sku' => '$p1.sku$', 'source_code' => '$source.source_code$', 'quantity' => 10, 'status' => 1],
            ['sku' => '$p2.sku$', 'source_code' => '$source.source_code$', 'quantity' => 20, 'status' => 1],
        ]
    ),
    DataFixture(Indexer::class, as: 'indexer')
]
public function testInventoryConfiguration(): void
{
    $stock = DataFixtureStorageManager::getStorage()->get('stock');
    $product1 = DataFixtureStorageManager::getStorage()->get('p1');
    // Test inventory logic
}
```

--------------------------------

### Build Project with MFTF

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/commands/mftf.md

Builds the Codeception project by cloning example configuration files. The `--upgrade` option can be used to upgrade all installed tests after a major framework upgrade.

```bash
vendor/bin/mftf build:project
vendor/bin/mftf build:project --upgrade
```

--------------------------------

### Install MFTF Dependencies

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Installs the necessary dependencies for the Magento Functional Testing Framework (MFTF) using Composer. This command should be run after cloning the MFTF repository.

```bash
cd magento2-functional-testing-framework
composer install
```

--------------------------------

### Generate and Run All MFTF Tests

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

These commands first generate all necessary test files using MFTF and then execute the functional tests using Codeception. The `generate:tests` command creates the test scripts, and `codecept run` executes them based on the provided configuration.

```bash
vendor/bin/mftf generate:tests
vendor/bin/codecept run functional -c dev/tests/acceptance/codeception.yml
```

--------------------------------

### Start Content Server for Local Development

Source: https://github.com/adobedocs/commerce-testing/blob/main/README.md

Starts the content server for local development of the documentation site. This command assumes you are in the root directory of the content repository. It typically runs on port 3003.

```bash
npm run dev
```

--------------------------------

### Build MFTF Project

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Builds the Magento Functional Testing Framework (MFTF) project. This command is essential after installing dependencies and before running tests.

```bash
bin/mftf build:project
```

--------------------------------

### MFTF Project Build and Configuration

Source: https://context7.com/adobedocs/commerce-testing/llms.txt

This section covers the initial setup and configuration of the Magento Functional Testing Framework (MFTF). It includes commands for installing Composer dependencies, building the project, generating URN catalogs for IDE integration, and configuring environment variables via a .env file and Magento CLI commands.

```bash
# Install MFTF dependencies
composer install

# Build the project
vendor/bin/mftf build:project

# Generate URN catalog for PhpStorm
vendor/bin/mftf generate:urn-catalog .idea/misc.xml
vendor/bin/mftf generate:urn-catalog --force .idea/misc.xml

# Build with configuration parameters
vendor/bin/mftf build:project --MAGENTO_BASE_URL=http://magento.local/ --MAGENTO_BACKEND_NAME=admin214365

# Upgrade tests after major MFTF update
vendor/bin/mftf build:project --upgrade

# Enable CLI commands
cp dev/tests/acceptance/.htaccess.sample dev/tests/acceptance/.htaccess
```

```bash
# dev/tests/acceptance/.env configuration
MAGENTO_BASE_URL=http://magento.test
MAGENTO_BACKEND_NAME=admin
MAGENTO_ADMIN_USERNAME=admin
# Password is set in credentials file

# Magento configuration commands
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 config:set web/seo/use_rewrites 1
bin/magento cache:clean config full_page
```

--------------------------------

### Legacy Fixture File Example (PHP)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/data-fixtures-guide.md

An example of a legacy fixture file written in PHP. These files directly execute database operations and cannot be parameterized, making them inflexible.

```php
<?php
use Magento\Catalog\Api\ProductRepositoryInterface;
use Magento\Catalog\Model\Product;
use Magento\TestFramework\Helper\Bootstrap;

$product = Bootstrap::getObjectManager()->create(Product::class);
$product->setTypeId('simple')
    ->setAttributeSetId(4)
    ->setName('Simple Product')
    ->setSku('simple')  // Fixed SKU - can't customize
    ->setPrice(10)      // Fixed price - can't customize
    ->setVisibility(4)
    ->setStatus(1);

Bootstrap::getObjectManager()
    ->get(ProductRepositoryInterface::class)
    ->save($product);

```

--------------------------------

### Serve Allure Reports

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Generates and serves visual representations of test report data using the Allure Framework. This command points to the directory where Allure results are stored.

```bash
allure serve dev/tests/acceptance/tests/_output/allure-results/
```

--------------------------------

### Build MFTF Project and Generate URN Catalog

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

These commands build the MFTF project and generate a URN catalog, which is essential for the framework to map test elements. The `build:project` command prepares the framework, and `generate:urn-catalog` creates the mapping file, optionally with `--force` to overwrite existing files.

```bash
vendor/bin/mftf build:project
vendor/bin/mftf generate:urn-catalog .idea/misc.xml
vendor/bin/mftf generate:urn-catalog --force .idea/misc.xml
```

--------------------------------

### Example Suite Configuration

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/using-suites.md

An example of an XML suite definition that disables WYSIWYG before running tests from the Catalog module and re-enables it afterward. It also excludes a specific incompatible test.

```xml
<suites xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:mftf:Suite/etc/suiteSchema.xsd">
    <suite name="WYSIWYGDisabledSuite">
        <before>
            <magentoCLI stepKey="disableWYSIWYG" command="config:set cms/wysiwyg/enabled disabled" />
        </before>
        <after>
            <magentoCLI stepKey="enableWYSIWYG" command="config:set cms/wysiwyg/enabled enabled" />
        </after>
        <include>
            <module name="Catalog"/>
        </include>
        <exclude>
            <test name="WYSIWYGIncompatibleTest"/>
        </exclude>
    </suite>
</suites>
```

--------------------------------

### XML: Build Form Element Selectors Efficiently

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/tips-tricks.md

Illustrates the correct and incorrect methods for building selectors for form elements in XML. The 'Good' example shows a more efficient selector by starting with a parent context and specifying the element's name attribute, while the 'Bad' example uses a less specific selector.

```xml
<element name="productName" type="input" selector="*[data-index='product-details'] input[name='product[name]']"/>
```

```xml
<element name="productName" type="input" selector=".admin__field[data-index=name] input"/>
```

--------------------------------

### Enable CLI Commands for MFTF

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This command copies the sample .htaccess file to enable the necessary rewrite rules for the Functional Testing Framework to interact with the Adobe Commerce or Magento Open Source instance via CLI commands during test execution.

```bash
cp dev/tests/acceptance/.htaccess.sample dev/tests/acceptance/.htaccess
```

--------------------------------

### Switch to Window Example

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test/actions.md

Switches the browser focus to a specific window identified by its name. This is crucial for handling scenarios where new windows or pop-ups are opened during the testing process.

```xml
<!-- Switch to a window with the `name` parameter of `newWindow`. -->
<switchToWindow userInput="newWindow" stepKey="switchToWindow"/>
```

--------------------------------

### Configure Environment Variables for MFTF

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This command opens the .env file in the vim editor for configuring essential environment variables required for running MFTF tests. Key parameters include the Magento base URL, admin path, and admin username.

```bash
vim dev/tests/acceptance/.env
```

--------------------------------

### Generate and Run a Specific MFTF Test

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This command generates and runs a single specified test, `AdminLoginSuccessfulTest`, and removes previously generated tests before running. The `--remove` flag ensures a clean slate for the test execution.

```bash
vendor/bin/mftf run:test AdminLoginSuccessfulTest --remove
```

--------------------------------

### Install Node.js Dependencies with npm

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/js/index.md

Installs all project dependencies defined in the package.json file. This is a prerequisite for running Grunt tasks and tests.

```bash
npm install
```

--------------------------------

### Build Tests Using Action Groups (XML)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/tips-tricks.md

Demonstrates how to construct tests using action groups, which promotes reusability and maintainability. This approach is beneficial for extension developers, allowing for centralized updates to test logic. The 'Good' example shows a well-structured test using action groups, while the 'Bad' example illustrates a less maintainable approach without them.

```xml
<test name="NavigateClamberWatchEntityTest">
    <annotations>
        <!--some annotations-->
    </annotations>

    <actionGroup ref="StorefrontOpenProductPageActionGroup" stepKey="openProductPage">
        <argument name="productUrl" value="{{ClamberWatch.url_key}}" />
    </actionGroup>
    <actionGroup ref="StorefrontAssertProductNameOnProductPageActionGroup" stepKey="assertProductName">
        <argument name="productName" value="{{ClamberWatch.name}}" />
    </actionGroup>
    <actionGroup ref="StorefrontAssertProductSkuOnProductPageActionGroup" stepKey="assertProductSku">
        <argument name="productSku" value="{{ClamberWatch.sku}}" />
    </actionGroup>
    <actionGroup ref="StorefrontAssertProductPriceOnProductPageActionGroup" stepKey="assertProductPrice">
        <argument name="productPrice" value="{{ClamberWatch.price}}" />
    </actionGroup>
    <actionGroup ref="StorefrontAssertProductImagesOnProductPageActionGroup" stepKey="assertProductImage">
        <argument name="productImage" value="{{ClamberWatch.image}}" />
    </actionGroup>
</test>
```

```xml
<test name="NavigateClamberWatchEntityTest">
    <annotations>
                <!--some annotations-->
    </annotations>

    <amOnPage url="{{StorefrontProductPage.url(ClamberWatch.url_key)}}" stepKey="openProductPage"/>
    <see selector="{{StorefrontProductInfoMainSection.productName}}" userInput="{{ClamberWatch.name}}" stepKey="seeProductName" />
    <see selector="{{StorefrontProductInfoMainSection.productSku}}" userInput="{{ClamberWatch.sku}}" stepKey="seeProductSku" />
    <see selector="{{StorefrontProductInfoMainSection.price}}" userInput="{{ClamberWatch.price}}" stepKey="seeProductPrice" />
    <waitForElementNotVisible selector="{{StorefrontProductMediaSection.gallerySpinner}}" stepKey="waitGallerySpinnerDisappear" />
    <seeElement selector="{{StorefrontProductMediaSection.gallery}}" stepKey="seeProductGallery" />
    <seeElement selector="{{StorefrontProductMediaSection.productImage(ClamberWatch.productImage)}}" stepKey="seeProductImage" />
    <click selector="{{StorefrontProductMediaSection.productImage(ClamberWatch.productImage)}}" stepKey="openFullscreenImage" />
    <waitForPageLoad stepKey="waitForGalleryLoaded" />
    <seeElement selector="{{StorefrontProductMediaSection.productImageFullscreen(ClamberWatch.productImage)}}" stepKey="seeFullscreenProductImage" />
</test>
```

--------------------------------

### Install Fontconfig Library on Ubuntu

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/js/index.md

Installs the fontconfig library on Ubuntu systems, which is a dependency for PhantomJS used in some testing environments. This resolves 'libfontconfig.so.1: cannot open shared object file' errors.

```bash
apt-get install fontconfig
```

--------------------------------

### Documenting Target Rule Fixture with Multiple Usage Examples

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/attributes/data-fixture.md

Illustrates how to document a data fixture, the Target Rule fixture, with multiple usage scenarios. This example shows how to create rules using both an array list for SKU checks and an associative array for OR conditions based on SKU values.

```php
/* 
*    Target Rule fixture creates a rule with conditions provided as an array.
*
*    Usage-1: Create target rule using array list. It will check SKU values is in (simple1,simple3) as condition.
*
*    #[
*        DataFixture(
*            RuleFixture::class,
*            [
*                'conditions' => [
*                    [
*                        'attribute' => 'sku',
*                        'operator' => '()',
*                        'value' => 'simple1,simple3'
*                    ]
*                ]
*            ],
*            'rule'
*        )
*    ]
*    
*    Usage-2: Create target rule using associative array. It will check if sku=simple1 OR sku=simple3 as condition.
*    
*    #[
*        DataFixture(
*            RuleFixture::class,
*            [
*                'conditions' => [
*                    'aggregator' => 'any',
*                    'conditions' => [
*                        [
*                            'attribute' => 'sku',
*                            'value' => 'simple1'
*                        ],
*                        [
*                            'attribute' => 'sku',
*                            'value' => 'simple3'
*                        ]
*                    ],
*                ],
*            ],
*            'rule'
*        )
*    ]
*/
```

--------------------------------

### Example Section Definition and Usage in XML

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/section/index.md

This example shows a concrete implementation of a `<section>` file, defining buttons for an admin category sidebar. It includes the XML definition for the `AdminCategorySidebarActionSection` and demonstrates how to reference one of its elements (AddSubcategoryButton) in a test's `<click>` action. This illustrates the practical application of sections for test automation.

```xml
<?xml version="1.0" encoding="utf-8"?>

<sections xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:mftf:Page/etc/SectionObject.xsd">
    <section name="AdminCategorySidebarActionSection">
        <element name="AddRootCategoryButton" type="button" selector="#add_root_category_button" timeout="30"/>
        <element name="AddSubcategoryButton" type="button" selector="#add_subcategory_button" timeout="30"/>
    </section>
</sections>
```

```xml
<!-- Click on the button with locator "#add_subcategory_button" on the web page-->
<click selector="{{AdminCategorySidebarActionSection.AddSubcategoryButton}}" stepKey="clickOnAddSubCategory"/>
```

--------------------------------

### Use Descriptive Step Keys in Tests (XML)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/tips-tricks.md

This snippet illustrates the importance of using descriptive names for `stepKey` attributes in test configurations. Clear and meaningful `stepKeys` enhance test readability and maintainability by avoiding ambiguity. The 'Good' examples demonstrate descriptive naming, while the 'Bad' examples show the less desirable use of generic or numbered keys.

```xml
<click selector="{{StorefrontNavigationSection.topCategory(SimpleSubCategory.name)}}" stepKey="clickSimpleSubCategoryLink" />
<waitForPageLoad stepKey="waitForSimpleSubCategoryPageLoad" />
<click selector="{{StorefrontCategoryMainSection.productLinkByHref(SimpleProduct.urlKey)}}" stepKey="clickSimpleProductLink" />
<waitForPageLoad stepKey="waitForSimpleProductPageLoad" />

<!-- Perform some actions / Assert product page -->

<click selector="{{StorefrontNavigationSection.topCategory(CustomCategory.name)}}" stepKey="clickCustomCategoryLink" />
<waitForPageLoad stepKey="waitForCustomCategoryPageLoad" />
<click selector="{{StorefrontCategoryMainSection.productLinkByHref(CustomSimpleProduct.urlKey)}}" stepKey="clickCustomSimpleProductLink" />
<waitForPageLoad stepKey="waitForCustomSimpleProductPageLoad" />
```

```xml
<click selector="{{StorefrontNavigationSection.topCategory(SimpleSubCategory.name)}}" stepKey="clickCategoryLink1" />
<waitForPageLoad stepKey="waitForPageLoad1" />
<click selector="{{StorefrontCategoryMainSection.productLinkByHref(SimpleProduct.urlKey)}}" stepKey="clickProductLink1" />
<waitForPageLoad stepKey="waitForPageLoad2" />

<!-- Perform some actions / Assert product page -->

<click selector="{{StorefrontNavigationSection.topCategory(CustomCategory.name)}}" stepKey="clickCategoryLink2" />
<waitForPageLoad stepKey="waitForPageLoad3" />
<click selector="{{StorefrontCategoryMainSection.productLinkByHref(CustomSimpleProduct.urlKey)}}" stepKey="clickProductLink2" />
<waitForPageLoad stepKey="waitForPageLoad4" />
```

```xml
<createData entity="BasicMsiStock1" stepKey="createCustomStock1"/>
<createData entity="BasicMsiStock2" stepKey="createCustomStock2"/>
<createData entity="BasicMsiStock3" stepKey="createCustomStock3"/>
<createData entity="BasicMsiStock4" stepKey="createCustomStock4"/>
```

--------------------------------

### Example Jasmine JavaScript Unit Test

Source: https://context7.com/adobedocs/commerce-testing/llms.txt

An example of a Jasmine test file written in JavaScript for testing a Magento UI component. It demonstrates how to define tests for functions like `addAction` and `getAction` using `describe`, `beforeEach`, and `it` blocks. Dependencies like `underscore` and the component itself are loaded using `define`.

```javascript
// Example Jasmine test file: app/code/Magento/Ui/base/js/grid/columns/actions.test.js
define([
    'underscore',
    'Magento_Ui/js/grid/columns/actions'
], function (_, Actions) {
    'use strict';

    describe('ui/js/grid/columns/actions', function () {
        var model, action;

        beforeEach(function () {
            model = new Actions({
                index: 'actions',
                name: 'listing_action',
                indexField: 'id',
                dataScope: '',
                rows: [{ identifier: 'row' }]
            });
            action = {
                index: 'delete',
                hidden: true,
                rowIndex: 0,
                callback: function() { return true; }
            };
        });

        it('Check addAction function', function () {
            expect(model.addAction('delete', action)).toBe(model);
        });

        it('Check getAction function', function () {
            var someAction = _.clone(action);
            someAction.index = 'edit';
            model.addAction('edit', someAction);
            expect(model.getAction(0, 'edit')).toEqual(someAction);
        });
    });
});
```

--------------------------------

### Install Functional Testing Framework (MFTF)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This command installs the Functional Testing Framework (MFTF) as a Composer dependency within your Adobe Commerce or Magento Open Source project. Ensure you are in the project root directory before running.

```bash
composer install
```

--------------------------------

### Test Step Merging Order Recommendation

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/best-practices.md

Explains the best practice for setting the merging order of test steps. It advises against depending on steps from potentially disabled modules and suggests ordering test steps based on reliable prerequisites, such as placing gift card product creation after simple product creation.

```xml
<test>
  <!-- Example: Ensure simple product creation happens before gift card creation -->
  <createData type="simpleProduct"/>
  <createData type="giftCardProduct"/>
</test>
```

--------------------------------

### Remove MFTF Composer Dependency

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Removes the Magento Functional Testing Framework (MFTF) as a development dependency from an Adobe Commerce or Magento Open Source installation. This is typically done when using MFTF as a standalone application.

```bash
composer remove magento/magento2-functional-testing-framework --dev -d <path to the Adobe Commerce or Magento Open Source root directory>
```

--------------------------------

### Test XML Structure and Best Practices

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/best-practices.md

Provides guidelines for writing effective test cases in XML. It recommends using specific wait actions like `<waitForElementVisible>` over generic `<wait>` actions, keeping tests short and granular, and utilizing comments for clarity. It also advises referencing sections instead of hardcoding selectors and limits one `<test>` tag per file.

```xml
<test>
  <!-- Use specific wait actions -->
  <waitForElementVisible selector="#someElement"/>
  <waitForLoadingMaskToDisappear/>
  
  <!-- Keep tests short and granular -->
  <!-- Use comments for clarity -->
  <comment>This step verifies the login functionality.</comment>
  
  <!-- Refer to sections -->
  <section name="AdminLoginPage"/>
</test>
```

--------------------------------

### Define Starting Test Structure in XML

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/merge-points/merge-tests.md

This XML snippet defines the structure of a starting test case, including annotations, setup (before), teardown (after), and action groups for testing Adobe Commerce functionality. It serves as the base for merging other test components.

```xml
<test name="AdminCreateSimpleProductTest">
    <annotations>
        <features value="Catalog"/>
        <stories value="Create a Simple Product via Admin"/>
        <title value="Admin should be able to create a Simple Product"/>
        <description value="Admin should be able to create a Simple Product"/>
        <severity value="CRITICAL"/>
        <testCaseId value="MAGETWO-23414"/>
        <group value="product"/>
    </annotations>
    <before>
        <createData entity="_defaultCategory" stepKey="createPreReqCategory"/>
    </before>
    <after>
        <amOnPage url="admin/admin/auth/logout/" stepKey="amOnLogoutPage"/>
        <deleteData createDataKey="createPreReqCategory" stepKey="deletePreReqCategory"/>
    </after>

    <actionGroup ref="AdminLoginActionGroup" stepKey="adminLoginActionGroup1"/>
    <actionGroup ref="AdminFillSimpleProductFormActionGroup" stepKey="fillProductFieldsInAdmin">
        <argument name="category" value="$$createPreReqCategory$$"/>
        <argument name="simpleProduct" value="_defaultProduct"/>
    </actionGroup>
    <actionGroup ref="AssertProductInStorefrontCategoryPage" stepKey="assertProductInStorefront1">
        <argument name="category" value="$$createPreReqCategory$$"/>
        <argument name="product" value="_defaultProduct"/>
    </actionGroup>
    <actionGroup ref="AssertProductInStorefrontProductPage" stepKey="assertProductInStorefront2">
        <argument name="product" value="_defaultProduct"/>
    </actionGroup>
</test>
```

--------------------------------

### Run a Specific MFTF Test

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Executes a single, specific functional test using the Magento Functional Testing Framework (MFTF). This is useful for targeted testing and debugging.

```bash
bin/mftf run:test AdminLoginSuccessfulTest
```

--------------------------------

### Create Simple Product Test in MFTF XML

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/test-prep.md

This MFTF XML test case outlines the steps to create a simple product in Adobe Commerce. It includes annotations, before and after setup (login/logout), and the core actions of navigating to the product page, adding a new product, and filling in product details. It highlights the use of hardcoded selectors and values.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
/**
  * Copyright [first year code created] Adobe
  * All Rights Reserved.

  */
-->

<tests xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="urn:magento:mftf:Test/etc/testSchema.xsd">
    <test name="CreateSimpleProductTest">
        <annotations>
            <features value="Catalog"/>
            <stories value="Create Product"/>
            <title value="Admin should be able to create simple product."/>
            <description value="Admin should be able to create simple product."/>
            <severity value="MAJOR"/>
            <group value="Catalog"/>
            <group value="alex" />
        </annotations>
        <before>
            <!-- Login to Admin panel -->
            <amOnPage url="admin" stepKey="openAdminPanelPage" />
            <fillField selector="#username" userInput="admin" stepKey="fillLoginField" />
            <fillField selector="#login" userInput="123123q" stepKey="fillPasswordField" />
            <click selector="#login-form .action-login" stepKey="clickLoginButton" />
        </before>
        <after>
            <!-- Logout from Admin panel -->
        </after>

        <!-- Navigate to Catalog -> Products page (or just open by link) -->
        <amOnPage url="admin/catalog/product/index" stepKey="openProductGridPage" />

        <!-- Click "Add Product" button -->
        <click selector="#add_new_product-button" stepKey="clickAddProductButton" />
        <waitForPageLoad stepKey="waitForNewProductPageOpened" />

        <!-- Fill field "Name" with "Simple Product %unique_value%" -->
  -----><fillField selector="input[name='product[name]']" userInput="Simple Product 12412431" stepKey="fillNameField" />

        <!-- Fill field "SKU" with "simple_product_%unique_value%" -->
        <fillField selector="input[name='product[sku]']" userInput="simple-product-12412431" stepKey="fillSKUField" />

        <!-- Fill field "Price" with "500.00" -->
        <fillField selector="input[name='product[price]']" userInput="500.00" stepKey="fillPriceField" />

        <!-- Fill field "Quantity" with "100" -->
        <fillField selector="input[name='product[quantity_and_stock_status][qty]']" userInput="100" stepKey="fillQtyField" />

        <!-- Fill field "Weight" with "100" -->
        <fillField selector="input[name='product[weight]']" userInput="100" stepKey="fillWeightField" />

        ...
    </test>
</tests>
```

--------------------------------

### Run Deployment Workflow - Shell

Source: https://github.com/adobedocs/commerce-testing/wiki/Commerce-Testing-Documentation

Command to trigger the GitHub Actions workflow for deploying the site to staging or production environments. Requires specific branch selection.

```bash
# Navigate to Actions > Deployment > Run workflow
# Select the branch to deploy
# Use default for 'Clean cache' (no)
# Click 'Run workflow'
```

--------------------------------

### Clone Magento 2 Source Code Repository

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Clones the magento2 source code repository using either HTTPS or SSH. This is the initial step to obtain the Magento codebase for testing.

```bash
git clone https://github.com/magento/magento2.git
```

```bash
git clone git@github.com:magento/magento2.git
```

--------------------------------

### Clean Magento Cache via CLI

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Cleans the configuration and full page cache for Adobe Commerce or Magento Open Source using the command-line interface. This command should be run after configuration changes.

```bash
bin/magento cache:clean config full_page
```

--------------------------------

### Disable WYSIWYG Editor via CLI

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Disables the WYSIWYG editor for Adobe Commerce or Magento Open Source using a command-line interface command. This is necessary for the Selenium web driver to interact with certain fields.

```bash
bin/magento config:set cms/wysiwyg/enabled disabled
```

--------------------------------

### Run PHPUnit with Specific Configuration (Bash)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/unit/command-line.md

Executes PHPUnit with a specific configuration file, often used to resolve issues related to extensions or custom configurations, such as the Allure extension. This command navigates to the unit test directory and then runs PHPUnit, specifying the path to the configuration and test files.

```bash
cd dev/tests/unit/
../../../vendor/bin/phpunit -c phpunit.xml.dist ../../../app/code/Example/Module/Test/Unit
```

--------------------------------

### Fixture Declaration Relative to Test Suite | PHP

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/annotations/magento-data-fixture.md

This example shows how to declare a data fixture using a path relative to the test suite directory (`dev/tests/integration/<test suite directory>`). The path should use forward slashes and not start with a leading slash.

```php
/**
 * @magentoDataFixture Magento/Cms/_files/pages.php
 */
```

--------------------------------

### Configure Global Test Settings (PHP)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/index.md

This example demonstrates how to configure global settings required for integration tests by modifying the `config-global.php` file. Add your path-value pairs for custom configurations, but do not remove existing entries.

```php
return [
    'customer/password/limit_password_reset_requests_method' => 0,
    'admin/security/admin_account_sharing' => 1,
    'admin/security/limit_password_reset_requests_method' => 0,
    'some/custom/path' => 'some-custom-value'
];

```

--------------------------------

### Codeception CLI Commands for Functional Testing

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/config.md

Demonstrates the usage of the Codeception command-line interface, which is the underlying framework for MFTF. These commands are used for running tests, generating code, and managing test suites.

```bash
# Run all tests
vendor/bin/codecept run

# Run tests in a specific group
vendor/bin/codecept run api

# Generate a new Cest file
vendor/bin/codecept generate:cest Acceptance User
```

--------------------------------

### Metadata Operations Example | Commerce Testing

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/metadata.md

Illustrates how to define different operations (create, update, delete, get) for the same data entity ('category') within a metadata file. This demonstrates the flexibility of the framework in handling various actions on a single entity type.

```xml
<operations>
    <operation type="create" dataType="category">
        ...
    </operation>
    <operation type="update" dataType="category">
        ...
    </operation>
    <operation type="delete" dataType="category">
        ...
    </operation>
    <operation type="get" dataType="category">
        ...
    </operation>
</operations>
```

--------------------------------

### Run All Unit Tests (Bash)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/unit/command-line.md

Executes all unit tests for Adobe Commerce or Magento Open Source. This command should be run from the application's root directory. It utilizes the PHPUnit executable found in the vendor directory and a specified configuration file.

```bash
./vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist
```

--------------------------------

### Example Usage of Data Fixtures with Transactions

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/attributes/data-fixture-before-transaction.md

Demonstrates the usage of DataFixtureBeforeTransaction and DataFixture attributes in a PHP test case. Fixtures defined with DataFixtureBeforeTransaction are applied before the transaction, while those with DataFixture are applied within the transaction, showcasing different data setup strategies for testing.

```php
class CategoryTest extends TestCase
{
    #[
        DataFixtureBeforeTransaction(ScheduleMode::class, ['indexer' => 'catalog_category_product']),
        DataFixtureBeforeTransaction(ScheduleMode::class, ['indexer' => 'catalog_product_category']),
        DataFixture(Category::class, as: 'category'),
        DataFixture(Product::class, ['category_ids' => ['$category.id$']], 'product1'),
        DataFixture(Product::class, ['category_ids' => ['$category.id$']], 'product2')
    ]
    public function testUpdateProductsPositionsWithIndexerOnSchedule(): void
    {

    }
}
```

--------------------------------

### Build Project with Environment Variables

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/commands/mftf.md

Builds the project and sets environment variables for Magento base URL and backend name. This command is used to configure the build process with specific environment settings.

```bash
vendor/bin/mftf build:project --MAGENTO_BASE_URL=http://magento.local/ --MAGENTO_BACKEND_NAME=admin214365
```

--------------------------------

### Integration Testing - MySQL Database Setup

Source: https://context7.com/adobedocs/commerce-testing/llms.txt

Creates a dedicated MySQL database and user for integration tests. This ensures that integration tests do not interfere with the production database and have a clean environment. Requires MySQL 8+.

```sql
-- MySQL 8+ database setup
CREATE DATABASE magento_integration_tests;
CREATE USER 'magento2_test_user'@'localhost' IDENTIFIED BY 'ftYx4pm6^x9.&^hB';
GRANT ALL PRIVILEGES ON magento_integration_tests.* TO 'magento2_test_user'@'localhost';
```

--------------------------------

### Configure Admin Security Settings via CLI

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

Configures security settings for the Adobe Commerce or Magento Open Source admin panel via the command-line interface. This includes enabling Admin Account Sharing and disabling secret key in URLs.

```bash
bin/magento config:set admin/security/admin_account_sharing 1
bin/magento config:set admin/security/use_form_key 0
```

--------------------------------

### Switch to IFrame Example

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test/actions.md

Sets the focus to a specific iframe within the page. It requires an iframe identifier (name or selector) and a step key. This is essential for interacting with elements inside iframes.

```xml
<!-- Set the focus to <iframe name="embeddedFrame" ... /> -->
<switchToIFrame userInput="embeddedFrame" stepKey="switchToIFrame"/>
```

--------------------------------

### Create Integration Test Database and User (SQL)

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/index.md

These SQL commands demonstrate how to create a dedicated database and a user account for running integration tests. It's crucial to use a separate database and user to prevent data loss in your live Commerce instance. The commands are provided for both older and newer MySQL versions.

```sql
CREATE DATABASE magento_integration_tests;
GRANT ALL ON magento_integration_tests.* TO 'magento2_test_user'@'localhost' IDENTIFIED BY 'ftYx4pm6^x9.&^hB';
```

```sql
CREATE DATABASE magento_integration_tests;
CREATE USER 'magento2_test_user'@'localhost' IDENTIFIED BY 'ftYx4pm6^x9.&^hB';
GRANT ALL PRIVILEGES ON magento_integration_tests.* TO 'magento2_test_user'@'localhost';
```

--------------------------------

### Nginx Location Block for CLI Commands

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This Nginx configuration block allows the Functional Testing Framework to execute Adobe Commerce or Magento Open Source command-line interface (CLI) commands within tests. It defines a specific location for handling requests to the command.php script.

```nginx
location ~* ^/dev/tests/acceptance/utils($|/) {
  root $MAGE_ROOT;
  location ~ ^/dev/tests/acceptance/utils/command.php {
      fastcgi_pass   fastcgi_backend;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      include        fastcgi_params;
  }
}
```

--------------------------------

### Initialize Web Unsecure Base URL in Commerce Testing

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/attributes/config-fixture.md

This PHP code snippet demonstrates the initialization of the web unsecure base URL for the commerce-testing project. It sets the URL to 'http://example.com/' and calls an initialization method. This process is crucial for setting up the testing environment correctly. Refer to the Adobe Experience League configuration guide for more details.

```php
$this->_object->initUnsecureBaseUrl(
            'web/unsecure/base_url',
            'http://example.com/'
        );
        $this->_object->initStoreAfter();
```

--------------------------------

### Configure Nginx for Web Server Rewrites

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/getting-started.md

This snippet shows how to enable Nginx web server rewrites for Adobe Commerce or Magento Open Source. It involves setting a configuration value via the command line and clearing the cache. This is necessary for SEO-related features to function correctly.

```bash
bin/magento config:set web/seo/use_rewrites 1
bin/magento cache:clean config full_page
```

--------------------------------

### Open Generated Allure Report

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/reporting.md

Launches the previously generated Allure report in your default web browser. If no report directory is specified, it defaults to 'allure-report/' in the current directory.

```bash
allure open dev/tests/acceptance/tests/_output/allure-report
```

```bash
allure open
```

--------------------------------

### Parameterized Data Fixture Example | PHP

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/data-fixtures-guide.md

Demonstrates a basic parameterized data fixture using PHP attributes. It sets a product's price and retrieves it from the fixture storage. Requires the DataFixture attribute and ProductFixture class.

```php
use Magento\TestFramework\Fixture\DataFixture;
use Magento\TestFramework\Fixture\DataFixtureStorageManager;

// Only override values that matter for your test. SKU is auto-generated with a unique value
#[DataFixture(ProductFixture::class, ['price' => 10.00], 'product')]
public function testProductExists(): void
{
    $fixtures = DataFixtureStorageManager::getStorage();
    $product = $fixtures->get('product');
}
```

--------------------------------

### Jasmine Test Structure for Magento UI Components

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/js/index.md

This JavaScript code demonstrates a typical Jasmine test suite for a Magento UI component, specifically the 'actions' column type. It utilizes `describe` and `it` blocks to define test cases and `beforeEach` for setup. The tests cover various functionalities of the Actions model, such as adding, getting, updating, and applying actions, as well as checking visibility and single/multiple action states.

```javascript
define([
    'underscore',
    'Magento_Ui/js/grid/columns/actions'
], function (_, Actions) {
    'use strict';

    describe('ui/js/grid/columns/actions', function () {
        var model,
            action;

        beforeEach(function () {
            model = new Actions({
                index: 'actions',
                name: 'listing_action',
                indexField: 'id',
                dataScope: '',
                rows: [{
                    identifier: 'row'
                }]
            });
            action = {
                index: 'delete',
                hidden: true,
                rowIndex: 0,
                callback: function() {
                    return true;
                }
            };
        });

        it('Check addAction function', function () {
            expect(model.addAction('delete', action)).toBe(model);
        });

        it('Check getAction function', function () {
            var someAction = _.clone(action);

            someAction.index = 'edit';
            model.addAction('edit', someAction);
            expect(model.getAction(0, 'edit')).toEqual(someAction);
        });

        it('Check getVisibleActions function', function () {
            var someAction = _.clone(action);

            someAction.hidden = false;
            someAction.index= 'view';
            model.addAction('delete', action);
            model.addAction('view', someAction);
            expect(model.getVisibleActions('0')).toEqual([someAction]);
        });

        it('Check updateActions function', function () {
            expect(model.updateActions()).toEqual(model);
        });

        it('Check applyAction function', function () {
            model.addAction('delete', action);
            expect(model.applyAction('delete', 0)).toEqual(model);
        });

        it('Check isSingle and isMultiple function', function () {
            var someAction = _.clone(action);

            action.hidden = false;
            model.addAction('delete', action);
            expect(model.isSingle(0)).toBeTruthy();
            someAction.hidden = false;
            someAction.index = 'edit';
            model.addAction('edit', someAction);
            expect(model.isSingle(0)).toBeFalsy();
            expect(model.isMultiple(0)).toBeTruthy();
        });

        it('Check isActionVisible function', function () {
            expect(model.isActionVisible(action)).toBeFalsy();
            action.hidden = false;
            expect(model.isActionVisible(action)).toBeTruthy();
        });
    });
});
```

--------------------------------

### XML for Test Case: Create Simple Product

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/test-writing/test-prep.md

This XML snippet defines a test case for creating a simple product. It includes annotations for features, stories, and severity, along with 'before' and 'after' steps for logging in and out of the admin panel. The core of the test involves navigating to the product grid, clicking 'Add Product', and filling in product details using variables.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
/**
  * Copyright [first year code created] Adobe
  * All Rights Reserved.
  */
-->

<tests xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:mftf:Test/etc/testSchema.xsd">
    <test name="CreateSimpleProductTest">
        <annotations>
            <features value="Catalog"/>
            <stories value="Create Product"/>
            <title value="Admin should be able to create simple product."/>
            <description value="Admin should be able to create simple product."/>
            <severity value="MAJOR"/>
            <group value="Catalog"/>
            <group value="alex" />
        </annotations>
        <before>
            <!-- Login to Admin panel -->
            <amOnPage url="admin" stepKey="openAdminPanelPage" />
            <fillField selector="#username" userInput="admin" stepKey="fillLoginField" />
            <fillField selector="#login" userInput="123123q" stepKey="fillPasswordField" />
            <click selector="#login-form .action-login" stepKey="clickLoginButton" />
        </before>
        <after>
            <!-- Logout from Admin panel -->
        </after>

        <!-- Navigate to Catalog -> Products page (or just open by link) -->
        <amOnPage url="{{AdminProductIndexPage.url}}" stepKey="openProductGridPage" />

        <!-- Click "Add Product" button -->
        <click selector="{{AdminProductGridActionSection.addProductBtn}}" stepKey="clickAddProductButton" />
        <waitForPageLoad stepKey="waitForNewProductPageOpened" />

        <!-- Fill field "Name" with "Simple Product %unique_value%" -->
  ----><fillField selector="{{AdminProductFormSection.productName}}" userInput="{{_defaultProduct.name}}" stepKey="fillNameField" />

        <!-- Fill field "SKU" with "simple_product_%unique_value%" -->
        <fillField selector="{{AdminProductFormSection.productSku}}" userInput="{{_defaultProduct.sku}}" stepKey="fillSKUField" />

        <!-- Fill field "Price" with "500.00" -->
        <fillField selector="{{AdminProductFormSection.productPrice}}" userInput="{{_defaultProduct.price}}" stepKey="fillPriceField" />

        <!-- Fill field "Quantity" with "100" -->
        <fillField selector="{{AdminProductFormSection.productQuantity}}" userInput="{{_defaultProduct.quantity}}" stepKey="fillQtyField" />

        <!-- Fill field "Weight" with "100" -->
        <fillField selector="{{AdminProductFormSection.productWeight}}" userInput="{{_defaultProduct.weight}}" stepKey="fillWeightField" />

       ...
    </test>
</tests>
```

--------------------------------

### Reference Fixture Data with Aliases in PHP

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/guide/integration/data-fixtures-guide.md

Shows how to use fixture aliases with the `as` parameter to reference data from one fixture in another. This example demonstrates creating a category and then a product associated with that category.

```php
#[
    DataFixture(CategoryFixture::class, as: 'category'),
    DataFixture(ProductFixture::class, ['category_ids' => ['$category.id$']])
]
```

--------------------------------

### Integration Testing - Run PHPUnit Tests from CLI

Source: https://context7.com/adobedocs/commerce-testing/llms.txt

Executes integration tests using PHPUnit from the command line. Tests must be run from the `dev/tests/integration` directory. Supports running all tests, specific suites, directories, or individual classes/methods.

```bash
# Navigate to integration test directory
cd dev/tests/integration

# Run all integration tests
../../../vendor/bin/phpunit

# Run specific test suite
../../../vendor/bin/phpunit --testsuite "Memory Usage Tests"

# Run tests from a specific directory
../../../vendor/bin/phpunit ../../../app/code/Acme/Example/Test/Integration

# Run a single test class
../../../vendor/bin/phpunit ../../../app/code/Acme/Example/Test/Integration/ExampleTest.php

# Run a single test method
../../../vendor/bin/phpunit --filter 'testOnlyThisOneIsExecuted' ../../../app/code/Acme/Example/Test/Integration/ExampleTest.php
```

--------------------------------

### Run All Codecept Test Suites

Source: https://github.com/adobedocs/commerce-testing/blob/main/src/pages/functional-testing-framework/commands/codeception.md

A simple command to execute all defined test suites within the Codeception framework. This is a basic entry point for test execution.

```bash
vendor/bin/codecept run
```