From 2c7681eb57218af655914ea8046b74dc674b72fa Mon Sep 17 00:00:00 2001
From: helena <48861601+helenanull@users.noreply.github.com>
Date: Tue, 30 Mar 2021 22:29:01 +0300
Subject: [PATCH] Update README.md

---
 README.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index af08195..6726f3e 100644
--- a/README.md
+++ b/README.md
@@ -42,11 +42,11 @@ Selectors are located in `cypress/selectors` folder [only difference from cypres
 
 ## :grey_question: Q&A
 1. Why keep selectors separately (not hard-coded to tests)
-    - **tests are much more readable** - css selectors are by nature hard to read - even if we add data-test attributes. We might need 2nd child or want to verify that selector is a child for another element, like `.class2 > ul:nth-child(2)` (alternative `get().find()` or `get().parent()` is bad practice because of [this](https://docs.cypress.io/guides/core-concepts/retry-ability.html#Only-the-last-command-is-retried) )
-    - in large projects, we might need to re-use the same selectors. Example: in login test, we want to verify that login was successful and we check settings link in header. But the same settings link is also used in header test.
-    - selector and test logic is separated - when selector is updated, we just need to update selector file and not tests
-2. Is it still E2E test if we use API to login in settings test?
-     - since end result will be the same - it will catch exactly the same bugs as `full flow/user journey` E2E test would find, (we need to be careful not to leave 'gaps' though), it is E2E - tests are just separated and independent with this approach, **test suite is E2E**, one test might not be. 
+    - **tests are much more readable** - css selectors are by design hard to read - even if we add data-test attributes. We might need 2nd child or want to verify that selector is a child for another element, like `.class2 > ul:nth-child(2)` (alternative `get().find()` or `get().parent()` is bad practice because of [this](https://docs.cypress.io/guides/core-concepts/retry-ability.html#Only-the-last-command-is-retried) )
+    - in large projects, we might need to re-use the same selectors. Example: in login test, we want to verify that login was successful and for that, we check settings link visibility in header. But the same settings link is also used in header test.
+    - selector and test logic is separated - when selector is updated, we just need to update 1 selector file and not multiple tests
+2. Is it still E2E test if we use API to login in?
+     - since end result will be the same - it will catch exactly the same bugs as `full flow/user journey` E2E test would find, (we need to be careful not to leave 'gaps' though), it is E2E - tests are just separated and independent with this approach, **test suite is E2E**, one test might not be. Example: We have a bug where login button is not working - our settings test would pass(if there are no bugs in settings), but login test would still fail.
 4. Why mobile view is in config and not in test (like cy.viewport())?
     - we can't change userAgent in the middle of the test:
         https://github.com/cypress-io/cypress/issues/2100