From 0aaa3571b9727b97472e12dc502bbae6c8a5dacf Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Tue, 4 Jun 2019 14:53:25 -0500 Subject: [PATCH 1/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs --- .../coding-standards/technical-guidelines.md | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index cba76c2ca75..e2dbe42e74b 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -715,6 +715,61 @@ You need to read configuration from different sources (like database or filesyst 11.2.3. `ObjectManagerHelper` MAY BE used to automatically mock all dependencies of the object under test. +### 11.3. Functional Testing + +11.3.1. Action Groups + +11.3.1.1. Action group names MUST be brief but comprehensive. + +11.3.1.2. Action group arguments MUST specify their type. + +11.3.1.3. Action groups MUST NOT have unused arguments. + +11.3.1.4. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. + +11.3.1.5. Action groups SHOULD be in their own file. + +11.3.1.6. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. + +11.3.2. Elements + +11.3.2.1. Selectors SHOULD be written in CSS instead of Xpath when possible. + +11.3.2.2. CSS and Xpath selectors MUST be implemented in their most simple form. + +11.3.2.3. Xpath selectors MUST NOT use `@class="foo"`. + +11.3.2.4. CSS and Xpath selectors MUST NOT reference `@data-bind`. + +11.3.2.5. Parameterized selectors MUST use descriptive names for the parameters. + +11.3.2.6. Elements SHOULD use `timeout="30"` to wait after interactions. + +11.3.3. Test Before Block + +11.3.3.1. Configuration changes via `magentoCLI` SHOULD occur last in the `before` block. + +11.3.3.2. The `before` block SHOULD mostly be `createData` calls with minimal UI interaction. + +11.3.4. Test After Block + +11.3.4.1. Configuration changes via `magentoCLI` SHOULD occur first in the `after` block. + +11.3.4.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. + +11.3.5. Test Body + +11.3.5.1. The test SHOULD re-use action groups, pages, sections, and elements. + +11.3.5.2. Any data created MUST be deleted in the `after` block of the test. + +11.3.5.3. `amOnPage` SHOULD be followed by `waitForPageLoad`. + +11.3.5.4. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. + +11.3.5.5. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. + + ## 12. Web API 12.1. Both REST and SOAP API's MUST be exposed. From 840bd7233b1d3bc4fbdd5768f1ace85814208e9c Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Wed, 5 Jun 2019 11:36:55 -0500 Subject: [PATCH 2/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs - Added content from MFTF devdocs Best Practices page --- .../coding-standards/technical-guidelines.md | 73 ++++++++++++++++++- 1 file changed, 72 insertions(+), 1 deletion(-) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index e2dbe42e74b..6d7104f40ef 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -731,6 +731,16 @@ You need to read configuration from different sources (like database or filesyst 11.3.1.6. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. +11.3.1.7. Action group arguments SHOULD specify default values. + +11.3.1.8. Action group file names MUST follow this pattern: + +* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml + +* Example: AssertStorefrontMinicartContainsProductActionGroup.xml + +11.3.1.9. Action group names SHOULD match the file name that they are in. + 11.3.2. Elements 11.3.2.1. Selectors SHOULD be written in CSS instead of Xpath when possible. @@ -757,7 +767,7 @@ You need to read configuration from different sources (like database or filesyst 11.3.4.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. -11.3.5. Test Body +11.3.5. Test 11.3.5.1. The test SHOULD re-use action groups, pages, sections, and elements. @@ -769,6 +779,67 @@ You need to read configuration from different sources (like database or filesyst 11.3.5.5. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. +11.3.5.6. Test file names MUST follow this pattern: + +* {Admin or Storefront}{Functionality}Test.xml + +* Example: StorefrontCreateCustomerTest.xml + +11.3.5.7. `wait` SHOULD NOT be used unless for very specific circumstances. + +11.3.5.8. Tests SHOULD be short and granular. + +11.3.5.9. Comments SHOULD be used to ensure tests are readable and maintainable. + +11.3.6. Extending + +11.3.6.1. You SHOULD use extends in your new test or action group when at least one of the following conditions is applicable to your case: + +* You want to keep the original test without any modifications. + +* You want to create a new test that follows the same path as the original test. + +* You want a new action group that behaves similarly to the existing action group, but you do not want to change the functionality of the original action group. + +11.3.6.2. You SHOULD NOT use extends in the following conditions: + +* You want to change the functionality of the test or action group and do not need to run the original version. + +* You plan to merge the base test or action group. + +11.3.7. Annotations + +11.3.7.1. You SHOULD use `` to describe tests and action groups. + +11.3.7.2. You SHOULD update your annotations when updating tests. + +11.3.8. Data Entities + +11.3.8.1. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. + +11.3.8.2. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. + +11.3.8.3. Data entity file names MUST follow this pattern: + +* {Type}Data.xml, where Type represents the entity type. + +* Example: ProductData.xml + +11.3.9. Sections + +11.3.9.1. Section file names MUST follow this pattern: + +* {Admin or Storefront}{UI Description}Section.xml, where UI Description briefly describes the UI under test. + +* Example: AdminNavbarSection.xml + +11.3.10. Pages + +11.3.10.1. Page file names MUST follow this pattern: + +* {Admin or Storefront}{UI Description}Page.xml, where UI Description briefly describes the UI under tests. + +* Example: AdminLoginPage.xml ## 12. Web API From cf65d565f8c108d0c9dcd1dae224d461e4631173 Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Wed, 5 Jun 2019 15:58:15 -0500 Subject: [PATCH 3/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs - Copy over content from MFTF devdocs Tips and Tricks page --- .../coding-standards/technical-guidelines.md | 292 ++++++++++++++++++ 1 file changed, 292 insertions(+) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index 6d7104f40ef..3094ffabe60 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -741,6 +741,41 @@ You need to read configuration from different sources (like database or filesyst 11.3.1.9. Action group names SHOULD match the file name that they are in. +11.3.1.10. **You SHOULD use parameterized selectors in action groups with argument references.** Clarity and readability are important factors in good test writing. Having to parse through unreadable code can be time consuming. Save time by writing clearly. The good example clearly shows what the selector arguments refer to. In the bad example we see two parameters being passed into the selector with little clue as to their purpose. + +**Why?** The next person maintaining the test or extending it may not be able to understand what the parameters are referencing. + +{% collapsible Examples: %} + +### Recommended + +```xml + + + + + + + + + + + + + + +``` + +### Not recommended + +```xml + + + +``` + +{% endcollapsible %} + 11.3.2. Elements 11.3.2.1. Selectors SHOULD be written in CSS instead of Xpath when possible. @@ -755,6 +790,88 @@ You need to read configuration from different sources (like database or filesyst 11.3.2.6. Elements SHOULD use `timeout="30"` to wait after interactions. +11.3.2.7. **Xpath selectors should wrap `text()` with `contains()`.** When possible, use `contains(text(), 'someTextHere')` rather than `text()='someTextHere'`. `contains()` ignores whitespace while `text()` accounts for it. + +**Why?** If you are comparing text within a selector and have an unexpected space, or a blank line above or below the string, `text()` will fail while the `contains(text())` format will catch it. In this scenario `text()` is more exacting. Use it when you need to be very precise about what is getting compared. + +{% collapsible Examples: %} + +### Recommended + +```xml +//span[contains(text(), 'SomeTextHere')] +``` + +### Not recommended + +```xml +//span[text()='SomeTextHere'] +``` + +{% endcollapsible %} + +11.3.2.8. **Selectors should be built in the proper order.** When building selectors for form elements, start with the parent context of the form element. Then specify the element `name` attribute in your selector to ensure the correct element is targeted. To build a selector for an input, use the pattern: `{{section_selector}}` `{{input_selector}}` or for a button: `{{section_selector}}` `{{button_selector}}` + +**Why?** Traversing the DOM takes a finite amount of time and reducing the scope of the selector makes the selector lookup as efficient as possible. + +{% collapsible Examples: %} + +### Recommended + +```xml + +``` + +### Not recommended + +```xml + +``` + +{% endcollapsible %} + +11.3.2.9. **Selectors should be built with appropriate specificity.** Selectors that are too general might sweep up unexpected elements. When possible, select the first parent tag and then specify the desired element within that selection. + +**Why?** Elements that are overly specific are less flexible and may fail if unexpected DOM changes occur. It also reduces the amount of the DOM it needs to parse. + +{% collapsible Examples: %} + +### Recommended + +```xml +form[name='myform'] > input[name='firstname'] + +//*[@id='container'][@class='dashboard-title'] +``` + +### Not recommended + +```xml +input[name='firstname'] + +//*[@id='container']/*[@class='dashboard-advanced-reports']/*[@class='dashboard-advanced- reports-description']/*[@class='dashboard-title'] +``` + +{% endcollapsible %} + +11.3.2.10. Parameterized selectors MUST use descriptive variable names. + +{% collapsible Examples: %} + +### Recommended + +```xml + +``` + +### Not recommended + +```xml + +``` + +{% endcollapsible %} + 11.3.3. Test Before Block 11.3.3.1. Configuration changes via `magentoCLI` SHOULD occur last in the `before` block. @@ -767,6 +884,50 @@ You need to read configuration from different sources (like database or filesyst 11.3.4.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. +11.3.4.3. **You SHOULD perform the most critical actions first in the `` block.** Perform non-browser driving actions first. These are more likely to succeed as no UI is involved. In the good example, `magentoCLI` and `deleteData` are run first to ensure a proper state. In the bad example, we perform some heavy UI steps first. + +**Why?** If something goes wrong there, then the critical `magentoCLI` commands may not get a chance to run, leaving Magento configured incorrectly for any upcoming tests. + +{% collapsible Examples: %} + +### Recommended + +```xml + + + + + + + + + + + + + +``` + +### Not recommended + +```xml + + + + + + + + + + + + + +``` + +{% endcollapsible %} + 11.3.5. Test 11.3.5.1. The test SHOULD re-use action groups, pages, sections, and elements. @@ -791,6 +952,119 @@ You need to read configuration from different sources (like database or filesyst 11.3.5.9. Comments SHOULD be used to ensure tests are readable and maintainable. +11.3.5.10. **`see` and `seeElement` SHOULD be used wisely.** If you need to see some element and verify that the text inside is shown correctly, use the `see` action. If you need to verify that element present on page, use `seeElement`. But never use `seeElement` and build a Xpath which contains the expected text. + +**Why?** For `see` it will output something similar to this: `Failed asserting that any element by #some_selector contains text "some_text"` And for `seeElement` it will output something like this: `Element by #some_selector is not visible.` There is a subtle distinction: The first is a failure but it is the desired result: a ‘positive failure’. The second is a proper result of the action. + +{% collapsible Examples: %} + +### Recommended + +```xml + +``` + +### Not recommended + +```xml + +``` + +{% endcollapsible %} + +11.3.5.11. **Tests SHOULD be built from action groups.** + +**Why?** For extension developers, this will make it easier to extend or customize tests. Extending a single action group will update all tests that use this group. This improves maintainability as multiple instances of a failure can be fixed with a single action group update. + +{% collapsible Examples: %} + +### Recommended + +```xml + + + + + + + + + + + + + + + + + + + + + +``` + +### Not recommended + +```xml + + + + + + + + + + + + + + + + +``` + +{% endcollapsible %} + +11.3.5.12. `stepKey` names MUST be descriptive. This helps with readability and clarity. + +{% collapsible Examples: %} + +### Recommended + +```xml + + + + + + + + + + + +``` + +### Not recommended + +```xml + + + + + + + + + + + +``` + +{% endcollapsible %} + 11.3.6. Extending 11.3.6.1. You SHOULD use extends in your new test or action group when at least one of the following conditions is applicable to your case: @@ -825,6 +1099,24 @@ You need to read configuration from different sources (like database or filesyst * Example: ProductData.xml +11.3.8.4. **Data references SHOULD be used instead of hardcoded values.** If you need to run a command such as ``, do not hardcode paths and values to the command. Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command. It will simplify the future maintanence of tests. + +{% collapsible Examples: %} + +### Recommended + +```xml + +``` + +### Not recommended + +```xml + +``` + +{% endcollapsible %} + 11.3.9. Sections 11.3.9.1. Section file names MUST follow this pattern: From 0eb18946e23d1b0626da45a2894b996cffae2267 Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Thu, 6 Jun 2019 10:56:10 -0500 Subject: [PATCH 4/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs - Style tweaks - Reordered sections for better flow, less jumping around of topics --- .../coding-standards/technical-guidelines.md | 266 +++++++++--------- 1 file changed, 133 insertions(+), 133 deletions(-) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index 3094ffabe60..97a108921a4 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -717,174 +717,226 @@ You need to read configuration from different sources (like database or filesyst ### 11.3. Functional Testing -11.3.1. Action Groups +#### 11.3.1. Pages -11.3.1.1. Action group names MUST be brief but comprehensive. +11.3.1.1. Page file names MUST follow this pattern: -11.3.1.2. Action group arguments MUST specify their type. +* {Admin or Storefront}{UI Description}Page.xml, where UI Description briefly describes the UI under tests. -11.3.1.3. Action groups MUST NOT have unused arguments. +* Example: AdminLoginPage.xml -11.3.1.4. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. +#### 11.3.2. Sections -11.3.1.5. Action groups SHOULD be in their own file. +11.3.2.1. Section file names MUST follow this pattern: -11.3.1.6. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. +* {Admin or Storefront}{UI Description}Section.xml, where UI Description briefly describes the UI under test. -11.3.1.7. Action group arguments SHOULD specify default values. +* Example: AdminNavbarSection.xml -11.3.1.8. Action group file names MUST follow this pattern: +#### 11.3.3. Elements -* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml +11.3.3.1. Selectors SHOULD be written in CSS instead of Xpath when possible. -* Example: AssertStorefrontMinicartContainsProductActionGroup.xml +11.3.3.2. CSS and Xpath selectors MUST be implemented in their most simple form. -11.3.1.9. Action group names SHOULD match the file name that they are in. +11.3.3.3. Xpath selectors MUST NOT use `@class="foo"`. -11.3.1.10. **You SHOULD use parameterized selectors in action groups with argument references.** Clarity and readability are important factors in good test writing. Having to parse through unreadable code can be time consuming. Save time by writing clearly. The good example clearly shows what the selector arguments refer to. In the bad example we see two parameters being passed into the selector with little clue as to their purpose. +11.3.3.4. CSS and Xpath selectors MUST NOT reference `@data-bind`. -**Why?** The next person maintaining the test or extending it may not be able to understand what the parameters are referencing. +11.3.3.5. Parameterized selectors MUST use descriptive names for the parameters. + +11.3.3.6. Elements SHOULD use `timeout="30"` to wait after interactions. + +11.3.3.7. **Xpath selectors SHOULD wrap `text()` with `contains()`.** When possible, use `contains(text(), 'someTextHere')` rather than `text()='someTextHere'`. `contains()` ignores whitespace while `text()` accounts for it. + +**Why?** If you are comparing text within a selector and have an unexpected space, or a blank line above or below the string, `text()` will fail while the `contains(text())` format will catch it. In this scenario `text()` is more exacting. Use it when you need to be very precise about what is getting compared. {% collapsible Examples: %} ### Recommended ```xml - - - - - - - - - - - - - - +//span[contains(text(), 'SomeTextHere')] ``` ### Not recommended ```xml - - - +//span[text()='SomeTextHere'] ``` {% endcollapsible %} -11.3.2. Elements +11.3.3.8. **Selectors SHOULD be built in the proper order.** When building selectors for form elements, start with the parent context of the form element. Then specify the element `name` attribute in your selector to ensure the correct element is targeted. To build a selector for an input, use the pattern: `{{section_selector}}` `{{input_selector}}` or for a button: `{{section_selector}}` `{{button_selector}}` -11.3.2.1. Selectors SHOULD be written in CSS instead of Xpath when possible. +**Why?** Traversing the DOM takes a finite amount of time and reducing the scope of the selector makes the selector lookup as efficient as possible. -11.3.2.2. CSS and Xpath selectors MUST be implemented in their most simple form. +{% collapsible Examples: %} -11.3.2.3. Xpath selectors MUST NOT use `@class="foo"`. +### Recommended -11.3.2.4. CSS and Xpath selectors MUST NOT reference `@data-bind`. +```xml + +``` + +### Not recommended -11.3.2.5. Parameterized selectors MUST use descriptive names for the parameters. +```xml + +``` -11.3.2.6. Elements SHOULD use `timeout="30"` to wait after interactions. +{% endcollapsible %} -11.3.2.7. **Xpath selectors should wrap `text()` with `contains()`.** When possible, use `contains(text(), 'someTextHere')` rather than `text()='someTextHere'`. `contains()` ignores whitespace while `text()` accounts for it. +11.3.3.9. **Selectors SHOULD be built with appropriate specificity.** Selectors that are too general might sweep up unexpected elements. When possible, select the first parent tag and then specify the desired element within that selection. -**Why?** If you are comparing text within a selector and have an unexpected space, or a blank line above or below the string, `text()` will fail while the `contains(text())` format will catch it. In this scenario `text()` is more exacting. Use it when you need to be very precise about what is getting compared. +**Why?** Elements that are overly specific are less flexible and may fail if unexpected DOM changes occur. It also reduces the amount of the DOM it needs to parse. {% collapsible Examples: %} ### Recommended ```xml -//span[contains(text(), 'SomeTextHere')] +form[name='myform'] > input[name='firstname'] + +//*[@id='container'][@class='dashboard-title'] ``` ### Not recommended ```xml -//span[text()='SomeTextHere'] +input[name='firstname'] + +//*[@id='container']/*[@class='dashboard-advanced-reports']/*[@class='dashboard-advanced- reports-description']/*[@class='dashboard-title'] ``` {% endcollapsible %} -11.3.2.8. **Selectors should be built in the proper order.** When building selectors for form elements, start with the parent context of the form element. Then specify the element `name` attribute in your selector to ensure the correct element is targeted. To build a selector for an input, use the pattern: `{{section_selector}}` `{{input_selector}}` or for a button: `{{section_selector}}` `{{button_selector}}` - -**Why?** Traversing the DOM takes a finite amount of time and reducing the scope of the selector makes the selector lookup as efficient as possible. +11.3.3.10. Parameterized selectors MUST use descriptive variable names. {% collapsible Examples: %} ### Recommended ```xml - + ``` ### Not recommended ```xml - + ``` {% endcollapsible %} -11.3.2.9. **Selectors should be built with appropriate specificity.** Selectors that are too general might sweep up unexpected elements. When possible, select the first parent tag and then specify the desired element within that selection. +#### 11.3.4. Data Entities -**Why?** Elements that are overly specific are less flexible and may fail if unexpected DOM changes occur. It also reduces the amount of the DOM it needs to parse. +11.3.4.1. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. + +11.3.4.2. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. + +11.3.4.3. Data entity file names MUST follow this pattern: + +* {Type}Data.xml, where Type represents the entity type. + +* Example: ProductData.xml + +11.3.4.4. **Data references SHOULD be used instead of hardcoded values.** If you need to run a command such as ``, do not hardcode paths and values to the command. Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command. It will simplify the future maintanence of tests. {% collapsible Examples: %} ### Recommended ```xml -form[name='myform'] > input[name='firstname'] - -//*[@id='container'][@class='dashboard-title'] + ``` ### Not recommended ```xml -input[name='firstname'] - -//*[@id='container']/*[@class='dashboard-advanced-reports']/*[@class='dashboard-advanced- reports-description']/*[@class='dashboard-title'] + ``` {% endcollapsible %} -11.3.2.10. Parameterized selectors MUST use descriptive variable names. +#### 11.3.5. Action Groups + +11.3.5.1. Action group names MUST be brief but comprehensive. + +11.3.5.2. Action group arguments MUST specify their type. + +11.3.5.3. Action groups MUST NOT have unused arguments. + +11.3.5.4. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. + +11.3.5.5. Action groups SHOULD be in their own file. + +11.3.5.6. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. + +11.3.5.7. Action group arguments SHOULD specify default values. + +11.3.5.8. Action group file names MUST follow this pattern: + +* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml + +* Example: AssertStorefrontMinicartContainsProductActionGroup.xml + +11.3.5.9. Action group names SHOULD match the file name that they are in. + +11.3.5.10. **You SHOULD use parameterized selectors in action groups with argument references.** Clarity and readability are important factors in good test writing. Having to parse through unreadable code can be time consuming. Save time by writing clearly. The good example clearly shows what the selector arguments refer to. In the bad example we see two parameters being passed into the selector with little clue as to their purpose. + +**Why?** The next person maintaining the test or extending it may not be able to understand what the parameters are referencing. {% collapsible Examples: %} ### Recommended ```xml - + + + + + + + + + + + + + + ``` ### Not recommended ```xml - + + + ``` {% endcollapsible %} -11.3.3. Test Before Block +#### 11.3.6. Annotations + +11.3.6.1. You SHOULD use `` to describe tests and action groups. -11.3.3.1. Configuration changes via `magentoCLI` SHOULD occur last in the `before` block. +11.3.6.2. You SHOULD update your annotations when updating tests. -11.3.3.2. The `before` block SHOULD mostly be `createData` calls with minimal UI interaction. +#### 11.3.7. Test Before Block -11.3.4. Test After Block +11.3.7.1. Configuration changes via `magentoCLI` SHOULD occur last in the `before` block. -11.3.4.1. Configuration changes via `magentoCLI` SHOULD occur first in the `after` block. +11.3.7.2. The `before` block SHOULD mostly be `createData` calls with minimal UI interaction. -11.3.4.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. +#### 11.3.8. Test After Block -11.3.4.3. **You SHOULD perform the most critical actions first in the `` block.** Perform non-browser driving actions first. These are more likely to succeed as no UI is involved. In the good example, `magentoCLI` and `deleteData` are run first to ensure a proper state. In the bad example, we perform some heavy UI steps first. +11.3.8.1. Configuration changes via `magentoCLI` SHOULD occur first in the `after` block. + +11.3.8.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. + +11.3.8.3. **You SHOULD perform the most critical actions first in the `` block.** Perform non-browser driving actions first. These are more likely to succeed as no UI is involved. In the good example, `magentoCLI` and `deleteData` are run first to ensure a proper state. In the bad example, we perform some heavy UI steps first. **Why?** If something goes wrong there, then the critical `magentoCLI` commands may not get a chance to run, leaving Magento configured incorrectly for any upcoming tests. @@ -928,31 +980,31 @@ input[name='firstname'] {% endcollapsible %} -11.3.5. Test +#### 11.3.9. Test Body -11.3.5.1. The test SHOULD re-use action groups, pages, sections, and elements. +11.3.9.1. The test SHOULD re-use action groups, pages, sections, and elements. -11.3.5.2. Any data created MUST be deleted in the `after` block of the test. +11.3.9.2. Any data created MUST be deleted in the `after` block of the test. -11.3.5.3. `amOnPage` SHOULD be followed by `waitForPageLoad`. +11.3.9.3. `amOnPage` SHOULD be followed by `waitForPageLoad`. -11.3.5.4. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. +11.3.9.4. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. -11.3.5.5. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. +11.3.9.5. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. -11.3.5.6. Test file names MUST follow this pattern: +11.3.9.6. Test file names MUST follow this pattern: * {Admin or Storefront}{Functionality}Test.xml * Example: StorefrontCreateCustomerTest.xml -11.3.5.7. `wait` SHOULD NOT be used unless for very specific circumstances. +11.3.9.7. `wait` SHOULD NOT be used unless for very specific circumstances. -11.3.5.8. Tests SHOULD be short and granular. +11.3.9.8. Tests SHOULD be short and granular. -11.3.5.9. Comments SHOULD be used to ensure tests are readable and maintainable. +11.3.9.9. Comments SHOULD be used to ensure tests are readable and maintainable. -11.3.5.10. **`see` and `seeElement` SHOULD be used wisely.** If you need to see some element and verify that the text inside is shown correctly, use the `see` action. If you need to verify that element present on page, use `seeElement`. But never use `seeElement` and build a Xpath which contains the expected text. +11.3.9.10. **`see` and `seeElement` SHOULD be used wisely.** If you need to see some element and verify that the text inside is shown correctly, use the `see` action. If you need to verify that element present on page, use `seeElement`. But never use `seeElement` and build a Xpath which contains the expected text. **Why?** For `see` it will output something similar to this: `Failed asserting that any element by #some_selector contains text "some_text"` And for `seeElement` it will output something like this: `Element by #some_selector is not visible.` There is a subtle distinction: The first is a failure but it is the desired result: a ‘positive failure’. The second is a proper result of the action. @@ -972,7 +1024,7 @@ input[name='firstname'] {% endcollapsible %} -11.3.5.11. **Tests SHOULD be built from action groups.** +11.3.9.11. **Tests SHOULD be built from action groups.** **Why?** For extension developers, this will make it easier to extend or customize tests. Extending a single action group will update all tests that use this group. This improves maintainability as multiple instances of a failure can be fixed with a single action group update. @@ -1027,7 +1079,7 @@ input[name='firstname'] {% endcollapsible %} -11.3.5.12. `stepKey` names MUST be descriptive. This helps with readability and clarity. +11.3.9.12. `stepKey` names MUST be descriptive. This helps with readability and clarity. {% collapsible Examples: %} @@ -1065,9 +1117,9 @@ input[name='firstname'] {% endcollapsible %} -11.3.6. Extending +#### 11.3.10. Extending -11.3.6.1. You SHOULD use extends in your new test or action group when at least one of the following conditions is applicable to your case: +11.3.10.1. You SHOULD use extends in your new test or action group when at least one of the following conditions is applicable to your case: * You want to keep the original test without any modifications. @@ -1075,64 +1127,12 @@ input[name='firstname'] * You want a new action group that behaves similarly to the existing action group, but you do not want to change the functionality of the original action group. -11.3.6.2. You SHOULD NOT use extends in the following conditions: +11.3.10.2. You SHOULD NOT use extends in the following conditions: * You want to change the functionality of the test or action group and do not need to run the original version. * You plan to merge the base test or action group. -11.3.7. Annotations - -11.3.7.1. You SHOULD use `` to describe tests and action groups. - -11.3.7.2. You SHOULD update your annotations when updating tests. - -11.3.8. Data Entities - -11.3.8.1. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. - -11.3.8.2. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. - -11.3.8.3. Data entity file names MUST follow this pattern: - -* {Type}Data.xml, where Type represents the entity type. - -* Example: ProductData.xml - -11.3.8.4. **Data references SHOULD be used instead of hardcoded values.** If you need to run a command such as ``, do not hardcode paths and values to the command. Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command. It will simplify the future maintanence of tests. - -{% collapsible Examples: %} - -### Recommended - -```xml - -``` - -### Not recommended - -```xml - -``` - -{% endcollapsible %} - -11.3.9. Sections - -11.3.9.1. Section file names MUST follow this pattern: - -* {Admin or Storefront}{UI Description}Section.xml, where UI Description briefly describes the UI under test. - -* Example: AdminNavbarSection.xml - -11.3.10. Pages - -11.3.10.1. Page file names MUST follow this pattern: - -* {Admin or Storefront}{UI Description}Page.xml, where UI Description briefly describes the UI under tests. - -* Example: AdminLoginPage.xml - ## 12. Web API 12.1. Both REST and SOAP API's MUST be exposed. From 5ee5da899f8080c4e56c6b45328a5de246150112 Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Mon, 10 Jun 2019 13:06:00 -0500 Subject: [PATCH 5/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs - Made review feedback changes --- .../coding-standards/technical-guidelines.md | 48 ++++++++++--------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index 97a108921a4..ec1d22b321b 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -831,16 +831,16 @@ input[name='firstname'] #### 11.3.4. Data Entities -11.3.4.1. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. - -11.3.4.2. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. - -11.3.4.3. Data entity file names MUST follow this pattern: +11.3.4.1. Data entity file names MUST follow this pattern: * {Type}Data.xml, where Type represents the entity type. * Example: ProductData.xml +11.3.4.2. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. + +11.3.4.3. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. + 11.3.4.4. **Data references SHOULD be used instead of hardcoded values.** If you need to run a command such as ``, do not hardcode paths and values to the command. Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command. It will simplify the future maintanence of tests. {% collapsible Examples: %} @@ -861,25 +861,25 @@ input[name='firstname'] #### 11.3.5. Action Groups -11.3.5.1. Action group names MUST be brief but comprehensive. +11.3.5.1. Action group file names MUST follow this pattern: -11.3.5.2. Action group arguments MUST specify their type. +* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml -11.3.5.3. Action groups MUST NOT have unused arguments. +* Example: AssertStorefrontMinicartContainsProductActionGroup.xml -11.3.5.4. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. +11.3.5.2. Action group names MUST be brief but comprehensive. -11.3.5.5. Action groups SHOULD be in their own file. +11.3.5.3. Action group arguments MUST specify their type. -11.3.5.6. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. +11.3.5.4. Action groups MUST NOT have unused arguments. -11.3.5.7. Action group arguments SHOULD specify default values. +11.3.5.5. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. -11.3.5.8. Action group file names MUST follow this pattern: +11.3.5.6. Action groups SHOULD be in their own file. -* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml +11.3.5.7. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. -* Example: AssertStorefrontMinicartContainsProductActionGroup.xml +11.3.5.8. Action group arguments SHOULD specify default values. 11.3.5.9. Action group names SHOULD match the file name that they are in. @@ -918,6 +918,8 @@ input[name='firstname'] {% endcollapsible %} +11.3.5.11. Action groups SHOULD have ``. + #### 11.3.6. Annotations 11.3.6.1. You SHOULD use `` to describe tests and action groups. @@ -982,21 +984,21 @@ input[name='firstname'] #### 11.3.9. Test Body -11.3.9.1. The test SHOULD re-use action groups, pages, sections, and elements. +11.3.9.1. Test file names MUST follow this pattern: -11.3.9.2. Any data created MUST be deleted in the `after` block of the test. +* {Admin or Storefront}{Functionality}Test.xml -11.3.9.3. `amOnPage` SHOULD be followed by `waitForPageLoad`. +* Example: StorefrontCreateCustomerTest.xml -11.3.9.4. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. +11.3.9.2. The test SHOULD re-use action groups, pages, sections, and elements. -11.3.9.5. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. +11.3.9.3. Any data created MUST be deleted in the `after` block of the test. -11.3.9.6. Test file names MUST follow this pattern: +11.3.9.4. `amOnPage` SHOULD be followed by `waitForPageLoad`. -* {Admin or Storefront}{Functionality}Test.xml +11.3.9.5. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. -* Example: StorefrontCreateCustomerTest.xml +11.3.9.6. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. 11.3.9.7. `wait` SHOULD NOT be used unless for very specific circumstances. From 957a51b66f9f4550949fa405632697908356a1f4 Mon Sep 17 00:00:00 2001 From: Tom Reece Date: Tue, 18 Jun 2019 12:54:56 -0500 Subject: [PATCH 6/7] MQE-1482: Add MFTF Tests technical guidelines to "Technical Guidelines" topic on DevDocs - Deliver only Pages and Sections topics that we went through as a team --- .../coding-standards/technical-guidelines.md | 419 +----------------- 1 file changed, 15 insertions(+), 404 deletions(-) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index ec1d22b321b..21dd94dc2d1 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -721,419 +721,30 @@ You need to read configuration from different sources (like database or filesyst 11.3.1.1. Page file names MUST follow this pattern: -* {Admin or Storefront}{UI Description}Page.xml, where UI Description briefly describes the UI under tests. +* {Admin or Storefront}{Description}Page.xml, where {Description} briefly describes the page under test. +* Use PascalCase. +* Example: AdminProductAttributeGridPage.xml -* Example: AdminLoginPage.xml +11.3.1.2. Page `name` attribute MUST be the same as the file name. -#### 11.3.2. Sections - -11.3.2.1. Section file names MUST follow this pattern: - -* {Admin or Storefront}{UI Description}Section.xml, where UI Description briefly describes the UI under test. - -* Example: AdminNavbarSection.xml - -#### 11.3.3. Elements - -11.3.3.1. Selectors SHOULD be written in CSS instead of Xpath when possible. - -11.3.3.2. CSS and Xpath selectors MUST be implemented in their most simple form. - -11.3.3.3. Xpath selectors MUST NOT use `@class="foo"`. - -11.3.3.4. CSS and Xpath selectors MUST NOT reference `@data-bind`. - -11.3.3.5. Parameterized selectors MUST use descriptive names for the parameters. - -11.3.3.6. Elements SHOULD use `timeout="30"` to wait after interactions. - -11.3.3.7. **Xpath selectors SHOULD wrap `text()` with `contains()`.** When possible, use `contains(text(), 'someTextHere')` rather than `text()='someTextHere'`. `contains()` ignores whitespace while `text()` accounts for it. - -**Why?** If you are comparing text within a selector and have an unexpected space, or a blank line above or below the string, `text()` will fail while the `contains(text())` format will catch it. In this scenario `text()` is more exacting. Use it when you need to be very precise about what is getting compared. - -{% collapsible Examples: %} - -### Recommended - -```xml -//span[contains(text(), 'SomeTextHere')] -``` - -### Not recommended - -```xml -//span[text()='SomeTextHere'] -``` - -{% endcollapsible %} - -11.3.3.8. **Selectors SHOULD be built in the proper order.** When building selectors for form elements, start with the parent context of the form element. Then specify the element `name` attribute in your selector to ensure the correct element is targeted. To build a selector for an input, use the pattern: `{{section_selector}}` `{{input_selector}}` or for a button: `{{section_selector}}` `{{button_selector}}` - -**Why?** Traversing the DOM takes a finite amount of time and reducing the scope of the selector makes the selector lookup as efficient as possible. - -{% collapsible Examples: %} - -### Recommended - -```xml - -``` - -### Not recommended - -```xml - -``` - -{% endcollapsible %} - -11.3.3.9. **Selectors SHOULD be built with appropriate specificity.** Selectors that are too general might sweep up unexpected elements. When possible, select the first parent tag and then specify the desired element within that selection. - -**Why?** Elements that are overly specific are less flexible and may fail if unexpected DOM changes occur. It also reduces the amount of the DOM it needs to parse. - -{% collapsible Examples: %} - -### Recommended - -```xml -form[name='myform'] > input[name='firstname'] - -//*[@id='container'][@class='dashboard-title'] -``` - -### Not recommended - -```xml -input[name='firstname'] - -//*[@id='container']/*[@class='dashboard-advanced-reports']/*[@class='dashboard-advanced- reports-description']/*[@class='dashboard-title'] -``` - -{% endcollapsible %} - -11.3.3.10. Parameterized selectors MUST use descriptive variable names. - -{% collapsible Examples: %} - -### Recommended - -```xml - -``` - -### Not recommended - -```xml - -``` - -{% endcollapsible %} - -#### 11.3.4. Data Entities - -11.3.4.1. Data entity file names MUST follow this pattern: - -* {Type}Data.xml, where Type represents the entity type. - -* Example: ProductData.xml - -11.3.4.2. Data entities SHOULD make use of `unique="suffix"` or `unique="prefix"` to ensure that tests using the entity can be repeatedely ran against the same environment. - -11.3.4.3. Data entities MUST NOT be modified and MUST NOT merge additional fields without complete understanding and verifying the usage of existing data in tests. New data entities SHOULD be created if you are not sure. - -11.3.4.4. **Data references SHOULD be used instead of hardcoded values.** If you need to run a command such as ``, do not hardcode paths and values to the command. Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command. It will simplify the future maintanence of tests. - -{% collapsible Examples: %} - -### Recommended - -```xml - -``` - -### Not recommended - -```xml - -``` - -{% endcollapsible %} - -#### 11.3.5. Action Groups - -11.3.5.1. Action group file names MUST follow this pattern: - -* {Assert}{Admin or Storefront}{Functionality}ActionGroup.xml - -* Example: AssertStorefrontMinicartContainsProductActionGroup.xml - -11.3.5.2. Action group names MUST be brief but comprehensive. - -11.3.5.3. Action group arguments MUST specify their type. - -11.3.5.4. Action groups MUST NOT have unused arguments. - -11.3.5.5. Action groups MUST NOT reference `$$createdData.property$$` or `$createdData.property$`. - -11.3.5.6. Action groups SHOULD be in their own file. - -11.3.5.7. Action groups SHOULD use the `string` type instead of `entity` unless many properties from the `entity` would be referenced. - -11.3.5.8. Action group arguments SHOULD specify default values. +11.3.1.3. Page `module` attribute MUST follow this pattern: -11.3.5.9. Action group names SHOULD match the file name that they are in. +* {VendorName}_{ModuleName} +* Example: Magento_Backend -11.3.5.10. **You SHOULD use parameterized selectors in action groups with argument references.** Clarity and readability are important factors in good test writing. Having to parse through unreadable code can be time consuming. Save time by writing clearly. The good example clearly shows what the selector arguments refer to. In the bad example we see two parameters being passed into the selector with little clue as to their purpose. +11.3.1.4. There MUST be only one `` entity per file. -**Why?** The next person maintaining the test or extending it may not be able to understand what the parameters are referencing. - -{% collapsible Examples: %} - -### Recommended - -```xml - - - - - - - - - - - - - - -``` - -### Not recommended - -```xml - - - -``` - -{% endcollapsible %} - -11.3.5.11. Action groups SHOULD have ``. - -#### 11.3.6. Annotations - -11.3.6.1. You SHOULD use `` to describe tests and action groups. - -11.3.6.2. You SHOULD update your annotations when updating tests. - -#### 11.3.7. Test Before Block - -11.3.7.1. Configuration changes via `magentoCLI` SHOULD occur last in the `before` block. - -11.3.7.2. The `before` block SHOULD mostly be `createData` calls with minimal UI interaction. - -#### 11.3.8. Test After Block - -11.3.8.1. Configuration changes via `magentoCLI` SHOULD occur first in the `after` block. - -11.3.8.2. The `after` block SHOULD mostly be `deleteData` calls with minimal UI interaction. - -11.3.8.3. **You SHOULD perform the most critical actions first in the `` block.** Perform non-browser driving actions first. These are more likely to succeed as no UI is involved. In the good example, `magentoCLI` and `deleteData` are run first to ensure a proper state. In the bad example, we perform some heavy UI steps first. - -**Why?** If something goes wrong there, then the critical `magentoCLI` commands may not get a chance to run, leaving Magento configured incorrectly for any upcoming tests. - -{% collapsible Examples: %} - -### Recommended - -```xml - - - - - - - - - - - - - -``` - -### Not recommended - -```xml - - - - - - - - - - - - - -``` - -{% endcollapsible %} - -#### 11.3.9. Test Body - -11.3.9.1. Test file names MUST follow this pattern: - -* {Admin or Storefront}{Functionality}Test.xml - -* Example: StorefrontCreateCustomerTest.xml - -11.3.9.2. The test SHOULD re-use action groups, pages, sections, and elements. - -11.3.9.3. Any data created MUST be deleted in the `after` block of the test. - -11.3.9.4. `amOnPage` SHOULD be followed by `waitForPageLoad`. - -11.3.9.5. `amOnPage` SHOULD use `Page.url` instead of a hardcoded URL. - -11.3.9.6. `waitForPageLoad` SHOULD be used instead of `waitForLoadingMaskToDisappear` or `waitForAjaxLoad`. - -11.3.9.7. `wait` SHOULD NOT be used unless for very specific circumstances. - -11.3.9.8. Tests SHOULD be short and granular. - -11.3.9.9. Comments SHOULD be used to ensure tests are readable and maintainable. - -11.3.9.10. **`see` and `seeElement` SHOULD be used wisely.** If you need to see some element and verify that the text inside is shown correctly, use the `see` action. If you need to verify that element present on page, use `seeElement`. But never use `seeElement` and build a Xpath which contains the expected text. - -**Why?** For `see` it will output something similar to this: `Failed asserting that any element by #some_selector contains text "some_text"` And for `seeElement` it will output something like this: `Element by #some_selector is not visible.` There is a subtle distinction: The first is a failure but it is the desired result: a ‘positive failure’. The second is a proper result of the action. - -{% collapsible Examples: %} - -### Recommended - -```xml - -``` - -### Not recommended - -```xml - -``` - -{% endcollapsible %} - -11.3.9.11. **Tests SHOULD be built from action groups.** - -**Why?** For extension developers, this will make it easier to extend or customize tests. Extending a single action group will update all tests that use this group. This improves maintainability as multiple instances of a failure can be fixed with a single action group update. - -{% collapsible Examples: %} - -### Recommended - -```xml - - - - - - - - - - - - - - - - - - - - - -``` - -### Not recommended - -```xml - - - - - - - - - - - - - - - - -``` - -{% endcollapsible %} - -11.3.9.12. `stepKey` names MUST be descriptive. This helps with readability and clarity. - -{% collapsible Examples: %} - -### Recommended - -```xml - - - - - - - - - - - -``` - -### Not recommended - -```xml - - - - - - - - - - - -``` - -{% endcollapsible %} - -#### 11.3.10. Extending - -11.3.10.1. You SHOULD use extends in your new test or action group when at least one of the following conditions is applicable to your case: - -* You want to keep the original test without any modifications. - -* You want to create a new test that follows the same path as the original test. +#### 11.3.2. Sections -* You want a new action group that behaves similarly to the existing action group, but you do not want to change the functionality of the original action group. +11.3.2.1. Section file names MUST follow this pattern: -11.3.10.2. You SHOULD NOT use extends in the following conditions: +* {Admin or Storefront}{Description}Section.xml, where {Description} briefly describes the section under test. +* Use PascalCase. +* Example: StorefrontCheckoutCartSummarySection.xml -* You want to change the functionality of the test or action group and do not need to run the original version. +11.3.2.2. Section `name` attribute MUST be the same as the file name. -* You plan to merge the base test or action group. +11.3.2.3. There MUST be only one `
` entity per file. ## 12. Web API From cbff6d5ba3da937a72790bb77901b4925fb96650 Mon Sep 17 00:00:00 2001 From: Donald Booth Date: Tue, 18 Jun 2019 13:48:01 -0500 Subject: [PATCH 7/7] Added PascalCase links. --- guides/v2.2/coding-standards/technical-guidelines.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/guides/v2.2/coding-standards/technical-guidelines.md b/guides/v2.2/coding-standards/technical-guidelines.md index 21dd94dc2d1..a9f2206e140 100644 --- a/guides/v2.2/coding-standards/technical-guidelines.md +++ b/guides/v2.2/coding-standards/technical-guidelines.md @@ -722,7 +722,7 @@ You need to read configuration from different sources (like database or filesyst 11.3.1.1. Page file names MUST follow this pattern: * {Admin or Storefront}{Description}Page.xml, where {Description} briefly describes the page under test. -* Use PascalCase. +* Use [PascalCase](http://wiki.c2.com/?PascalCase). * Example: AdminProductAttributeGridPage.xml 11.3.1.2. Page `name` attribute MUST be the same as the file name. @@ -739,7 +739,7 @@ You need to read configuration from different sources (like database or filesyst 11.3.2.1. Section file names MUST follow this pattern: * {Admin or Storefront}{Description}Section.xml, where {Description} briefly describes the section under test. -* Use PascalCase. +* Use [PascalCase](http://wiki.c2.com/?PascalCase). * Example: StorefrontCheckoutCartSummarySection.xml 11.3.2.2. Section `name` attribute MUST be the same as the file name.