You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`--config=[<default> or <singleRun> or <parallel>]`| Creates a single manifest file with a list of all tests. The default location is `tests/functional/Magento/FunctionalTest/_generated/testManifest.txt`.<br/> You can split the list into multiple groups using `--config=parallel`; the groups will be generated in `_generated/groups/` like `_generated/groups/group1.txt, group2.txt, ...`.</br> Available values: `default` (default), `singleRun`(same as `default`), and `parallel`.</br> Example: `generate:tests --config=parallel`. |
147
+
|`--config=[<default> or <singleRun> or <parallel>]`| Creates a single manifest file with a list of all tests. The default location is `tests/functional/Magento/FunctionalTest/_generated/testManifest.txt`.<br/> You can split the list into multiple groups using `--config=parallel`; the groups will be generated in `_generated/groups/` like `_generated/groups/group1.txt, group2.txt, ...`.<br/> Available values: `default` (default), `singleRun`(same as `default`), and `parallel`.<br/> Example: `generate:tests --config=parallel`. |
148
148
|`--force`| Forces test generation, regardless of the module merge order defined in the Magento instance. Example: `generate:tests --force`. |
149
149
|`-i,--time`| Set time in minutes to determine the group size when `--config=parallel` is used. The __default value__ is `10`. Example: `generate:tests --config=parallel --time=15`|
150
150
|`--tests`| Defines the test configuration as a JSON string.|
151
151
|`--allow-skipped`| Allows MFTF to generate and run tests marked with `<skip>.`|
152
-
|`--debug or --debug=[<none>]`| Performs schema validations on XML files. <br/> DEFAULT: `generate:tests` implicitly performs schema validation on merged files. It does not indicate the file name where the error is encountered. <br/> DEVELOPER: `--debug` performs per-file validation and returns additional debug information (such as the filename where an error occurred) when test generation fails because of an invalid XML schema. This option takes extra processing time. Use it after test generation has failed once.</br><br/> NONE: `--debug=none` skips debugging during test generation. Added for backward compatibility, it will be removed in the next MAJOR release.</br>|
152
+
|`--debug or --debug=[<none>]`| Performs schema validations on XML files. <br/> DEFAULT: `generate:tests` implicitly performs schema validation on merged files. It does not indicate the file name where the error is encountered. <br/> DEVELOPER: `--debug` performs per-file validation and returns additional debug information (such as the filename where an error occurred) when test generation fails because of an invalid XML schema. This option takes extra processing time. Use it after test generation has failed once.<br/>NONE: `--debug=none` skips debugging during test generation. Added for backward compatibility, it will be removed in the next MAJOR release.<br/>|
153
153
|`-r,--remove`| Removes the existing generated suites and tests cleaning up the `_generated` directory before the actual run. For example, `generate:tests SampleTest --remove` cleans up the entire `_generated` directory and generates `SampleTest` only.|
154
154
155
155
#### Examples of the JSON configuration
@@ -447,9 +447,9 @@ vendor/bin/mftf setup:env
447
447
448
448
The example parameters are taken from the `etc/config/.env.example` file.
449
449
450
-
### `static:checks`
450
+
### `static-checks`
451
451
452
-
Runs all MFTF static:checks on the test codebase that MFTF is currently attached to.
452
+
Runs all MFTF static-checks on the test codebase that MFTF is currently attached to.
453
453
454
454
#### Existing static checks
455
455
@@ -458,7 +458,7 @@ Runs all MFTF static:checks on the test codebase that MFTF is currently attached
The MFTF does not support executing CLI commands if your web server points to `<MAGE_ROOT_DIR>/pub` directory as recommended in the [Installation Guide][Installation Guide docroot]. For the MFTF to execute the CLI commands, the web server must point to the Magento root directory.
103
+
100
104
### Nginx settings {#nginx-settings}
101
105
102
106
If Nginx Web server is used on your development environment then **Use Web Server Rewrites** setting in **Stores** > Settings > **Configuration** > **Web** > **Search Engine Optimization** must be set to **Yes**.
# Git vs Composer installation of Magento with MFTF
2
+
3
+
Depending on how you plan to use Magnto code, there are different options for installing Magento.
4
+
5
+
## GitHub Installation
6
+
7
+
If you are contributing a pull request to the Magento 2 codebase, download Magento 2 from our GitHub repository. Contribution to the codebase is done using the 'fork and pull' model where contributors maintain their own fork of the repo. This repo is then used to submit a pull request to the base repo.
8
+
9
+
Install guide: [GitHub Installation][]
10
+
11
+
## Composer based Installation
12
+
13
+
A Composer install downloads released packages of Magento 2 from the composer repo [https://repo.magento.com](https://repo.magento.com).
14
+
15
+
All Magento modules and their MFTF tests are put under `<vendor>` directory, for convenience of 3rd party developers. With this setup, you can keep your custom modules separate from core modules. You can also develop modules in a separate VCS repository and add them to your `composer.json` which installs them into the `vendor` directory.
16
+
17
+
Install guide: [Composer based Installation][]
18
+
19
+
## MFTF Installation
20
+
21
+
After installing your Magento project in either of the above ways, the composer dependency `magento/magento2-functional-testing-framework` downloads and installs MFTF. MFTF is embedded in your Magento 2 installation and will cover your project with functional tests.
22
+
23
+
If you want to contribute a pull request into MFTF codebase, you will need to install MFTF in the [Standalone][] mode.
24
+
25
+
## Managing modules - Composer vs GitHub
26
+
27
+
### Via GitHub
28
+
29
+
Cloning the Magento 2 git repository is a way of installing where you do not have to worry about matching your codebase with production. Your version control system generally holds and manages your `app/code` folder and you can do manual, ad-hoc development here.
30
+
31
+
### Via Composer
32
+
33
+
Magento advocates the use of composer for managing modules. When you install a module through composer, it is added to `vendor/<vendor-name>/<module>`.
34
+
35
+
When developing your own module or adding MFTF tests to a module, you should not edit in `vendor` because a composer update could overwrite your changes. Instead, overwrite a module under `vendor` by adding files or cloning your module-specific Git repo to `app/code/<vendor-name>/<module>`.
36
+
37
+
To distribute the module and its tests, you can initialize a git repo and create a [composer package][]. In this way others will be able to download and install your module and access your tests as a composer package, in their `<vendor>` folder.
38
+
39
+
## MFTF test materials location
40
+
41
+
- For GitHub installations, MFTF test materials are located in `<magento_root>/app/code/<vendor_name>/<module_name>/Test/Mftf/`. This is the directory for new tests or to maintain existing ones.
42
+
- For Composer-based installations, MFTF test materials are located at `<magento_root>/vendor/<vendor_name>/<module_name>/Test/Mftf/`. This is the directory to run tests fetched by Composer.
43
+
44
+
The file structure under both paths is the same:
45
+
46
+
```tree
47
+
<Path>
48
+
├── ActionGroup
49
+
│ └── ...
50
+
├── Data
51
+
│ └── ...
52
+
├── Metadata
53
+
│ └── ...
54
+
├── Page
55
+
│ └── ...
56
+
├── Section
57
+
│ └── ...
58
+
└── Test
59
+
└── ...
60
+
```
61
+
62
+
## How ModuleResolver reads modules
63
+
64
+
With either type of installation, all tests and test data are read and merged by MFTF's ModuleResolver in this order:
There is no difference between having the test materials in `app/code` or in `/vendor`: it works the same. Composer-based installs may benefit teams when there is a need to match file systems in `development` and `production`.
72
+
73
+
If you are a contributing developer with an understanding of Git and Composer commands, you can choose the GitHub installation method instead.
74
+
75
+
<!-- Link definitions -->
76
+
77
+
[Composer based Installation]: https://devdocs.magento.com/guides/v2.3/install-gde/composer.html
Copy file name to clipboardExpand all lines: docs/merge_points/extend-data.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,8 @@
1
1
# Extend data entities
2
2
3
-
Extending an action group doesn't affect the existing action group.
3
+
Extending a data entity does not affect the existing data entity.
4
4
5
-
In this example we add a `<click>` command to check the checkbox that our extension added with a new action group for the simple product creation form.
5
+
In this example we update the quantity to 1001 and add a new piece of data relevant to our extension. Unlike merging, this will _not_ affect any other tests that use this data entity.
6
6
7
7
## Starting entity
8
8
@@ -67,4 +67,4 @@ Note that there are now two data entities below.
0 commit comments