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
Copy file name to clipboardExpand all lines: docs/test.md
+15-19
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
# Test
2
2
3
3
Test cases in the Magento Functional Testing Framework (MFTF) are defined in XML as [`<tests>`].
4
-
`<tests>` is a [Codeception test container][Codeception] that contains multiple individual tests with test metadata and before and after actions.
4
+
`<tests>` is a [Codeception test container][Codeception] that contains individual test [`<test>`]with its metadata ([`<annotations>`]), before ([`<before>`]) and after ([`<after>`]) section.
5
5
6
-
MFTF `<tests>` is considered a sequence of actions with associated parameters.
6
+
MFTF `<test>` is considered a sequence of actions with associated parameters.
7
7
Any failed [assertion] within a test constitutes a failed test.
@@ -18,7 +18,7 @@ The following diagram shows the structure of an MFTF test case:
18
18
19
19
## Format
20
20
21
-
The format of `<tests>` is:
21
+
The format of a test XML file is:
22
22
23
23
```xml
24
24
<?xml version="1.0" encoding="UTF-8"?>
@@ -44,26 +44,23 @@ The format of `<tests>` is:
44
44
45
45
The following conventions apply to MFTF tests:
46
46
47
-
* All names within the framework are in the CamelCase format.
48
-
*`<test>` name must be alphanumeric.
49
-
* Each action and action group has its own identifier `<stepKey>` for reference purposes.
50
-
* A test may have any number of [assertions][assertion] at any point within the `<test>`.
51
-
* If `<test>` is included in `<suite>`, it **cannot be generated in isolation** to the rest of the contents of the suite (see [suites] for details).
52
47
* One `<test>` tag is allowed per test XML file.
48
+
* All names within the framework are in the **PascalCase** format and must be alphanumeric.
49
+
* Each action and action group call should have its own identifier `<stepKey>`.
50
+
* A test may have any number of [assertions][assertion] at any point within the `<test>`.
51
+
* If `<test>` is included in [`<suite>`][suites], it **cannot be generated in isolation** from `<before>` and `<after>` section of the suite (see [suites] for details).
53
52
54
53
## Elements reference
55
54
56
-
There are several XML elements that are used in`<tests>` in the MFTF.
55
+
There are several XML elements that are used within`<test>` in the MFTF.
57
56
58
57
### tests {#tests-tag}
59
58
60
-
`<tests>` is a container for multiple tests. It is a group of test methods that define test flows within a test case.
61
-
62
-
`<tests>` must contain at least one [`<test>`].
59
+
`<tests>` is a container for test and must contain exactly one [`<test>`].
63
60
64
61
### test {#test-tag}
65
62
66
-
`<test>` is a set of steps, including [actions] and [assertions][assertion]. It is a sequence of test steps that define test flow within a test method.
63
+
`<test>` is a set of steps, including [actions], [assertions][assertion] and Action Group calls. It is a sequence of test steps that define test flow within a test method.
67
64
68
65
Attribute|Type|Use|Description
69
66
---|---|---|---
@@ -85,21 +82,20 @@ Allure annotations provide metadata for reporting.
85
82
86
83
### before {#before-tag}
87
84
88
-
`<before>` wraps the steps to perform before the [`<test>`].
85
+
`<before>` wraps the steps that are preconditions for the [`<test>`]. For example: Change configuration, create Customer Account, Create Category and Product.
89
86
90
87
`<before>` may contain these child elements:
91
88
92
-
* Any [`<action>`][actions]
93
-
*[`<actionGroup>`]
89
+
* Any [Action][actions]
90
+
*[`<actionGroup>`]s
94
91
95
92
### after {#after-tag}
96
93
97
-
`<after>` wraps the steps to perform after the [`<test>`].
98
-
The steps are run in both successful **and** failed test runs.
94
+
`<after>` wraps the steps to perform after the [`<test>`]. The steps are run in both successful **and** failed test runs. The goal of this section is to perform cleanup (revert the environment to the pre-test state).
0 commit comments