Где мои тесты Selenium проверяют ожидаемые/фактические результаты?

Question

В настоящее время я разрабатываю платформу тестирования для веб-приложения. Структура представляет собой гибридную (основанную на данных и ключевое слово) структуру. Я настроил его, поэтому у меня есть пакеты с функциями пользовательского интерфейса, которые я могу вызвать в тестовых классах для навигации и щелчка по приложению.

Мне интересно узнать о лучших практиках.

Должен ли я проверять результаты с каждым шагом, который я принимаю? Или я должен проверить результаты в конце теста?

Более подробно, это текущая структура моего теста с минимальным кодом:

// This test contains one step. The following method navigates to the page and inputs invalid credentials. 
// We than check if we're still on the login page. If we are, the test passes. If we can't find the 
// "login text", than the test has failed. 
     LoginPage.invalidCredentialsOne.run(driver); 
     Thread.sleep(2000); 

     WebElement logintext = driver.findElement(By.xpath(prop.getProperty("logintext"))); 
     if (logintext.getText().equals("LOG IN")) { 
      //add pass entry to the excel sheet 
      testresultdata.put("3", new Object[] { 
       2d, "User should not be able to login with an invalid password", "Login failed", "Pass" 
      }); 
      driver.close(); 
      Alert alert = driver.switchTo().alert(); 
      alert.accept(); 
     } else { 
      //add fail entry to the excel sheet 
      testresultdata.put("3", new Object[] { 
       2d, "User should not be able to login with an invalid password", "Login failed", "Fail" 
      }); 
      fail(); 
      driver.close(); 
      Alert alert = driver.switchTo().alert(); 
      alert.accept(); 
     } 

В приведенном выше коде, проверить наличие ожидаемых/фактических результатов ПОСЛЕ Я побежал метод. Было бы целесообразно проверить ожидаемые/фактические результаты внутри самого метода? Какими будут плюсы и минусы этого?

Я чувствую, что ожидаемые/фактические результаты в методе улучшат ремонтопригодность, а также точность тестирования (возможность увидеть, где именно ваш тест не прошел).

Или почему бы просто не проверить через оба?

Методы - проверьте каждую сделанную навигацию. Если сбой навигации, выведите строку в консоли, где вы скажете. Это проверяет простые ошибки пользовательского интерфейса.

Тестовые классы - проверьте более конкретные сценарии пользователя.

Очень заинтересованы в правильной передовой практике для этого. Заранее спасибо.

Answer 1

Я бы разделил тестовый подход (особенно с системными тестами, написанными в селене) на действие и проверку. Это означает, что вам необходимо разделить методы, приводящие к некоторой смене системы (например, ваши invalidCredentialsOne) и методы, которые должны проверить/проверить состояние системы после изменений.

Почему это хорошо? Таким образом, вы можете создавать свои пользовательские сценарии с помощью некоторого набора действий и проверять этот набор в нужном месте. Этот подход обеспечивает гибкость при построении различных сценариев и проверок.

Если мы вернемся к вашему примеру, предположим, что вы хотите протестировать не только то, что вы вернетесь на страницу входа в систему в случае неправильных учетных данных, но, например, после 5 попыток система (предположим, что!) Будет блокировать Пользователь. В этом случае вы можете использовать свое первое действие 5 раз, а затем проверить, блокирует ли система пользователя.

P.S. Пожалуйста, постарайтесь не использовать Thread.sleep в коде селена. Ожидание появления объекта намного лучше.