summaryrefslogtreecommitdiff
path: root/doc/development/testing_guide/end_to_end
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2020-02-11 21:08:44 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2020-02-11 21:08:44 +0000
commit0e9eea40b62fcae67b2bd885dbedd7525fbca3c7 (patch)
tree099467fd4c16441f60a879239056b235c7fdabdc /doc/development/testing_guide/end_to_end
parent1ca9950d5f890cd8f185e1eda158b969a7244fe2 (diff)
downloadgitlab-ce-0e9eea40b62fcae67b2bd885dbedd7525fbca3c7.tar.gz
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/testing_guide/end_to_end')
-rw-r--r--doc/development/testing_guide/end_to_end/dynamic_element_validation.md4
-rw-r--r--doc/development/testing_guide/end_to_end/page_objects.md4
2 files changed, 4 insertions, 4 deletions
diff --git a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
index aec0a3ede5a..32b1c304a9a 100644
--- a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
+++ b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
@@ -27,7 +27,7 @@ Runtime::Browser.visit(:gitlab, Some::Page)
### Clicks
-When we perform a click within our tests, we expect something to occur. That something could be a component to now
+When we perform a click within our tests, we expect something to occur. That something could be a component to now
appear on the webpage, or the test to navigate away from the page entirely.
Dynamic element validation is instituted when using
@@ -57,7 +57,7 @@ Simply put, a required element is a visible HTML element that appears on a UI co
#### Application
-Requiring elements is very easy. By adding `required: true` as a parameter to an `element`, you've now made it
+Requiring elements is very easy. By adding `required: true` as a parameter to an `element`, you've now made it
a requirement that the element appear on the page upon navigation.
## Examples
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index f1e0de0c792..22e7375be1f 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -152,7 +152,7 @@ Things to note:
- The name of the element and the qa_selector must match and be snake_cased
- If the element appears on the page unconditionally, add `required: true` to the element. See
[Dynamic element validation](dynamic_element_validation.md)
-- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector)
+- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector)
method of definition over the `.qa-selector` CSS class
### `data-qa-selector` vs `.qa-selector`
@@ -173,7 +173,7 @@ and we should prefer the `data-qa-selector` method of definition.
A common occurrence in automated testing is selecting a single "one-of-many" element.
In a list of several items, how do you differentiate what you are selecting on?
-The most common workaround for this is via text matching. Instead, a better practice is
+The most common workaround for this is via text matching. Instead, a better practice is
by matching on that specific element by a unique identifier, rather than by text.
We got around this by adding the `data-qa-*` extensible selection mechanism.