У меня есть тестовый пример, как показано ниже:
@Test
public void checkSomething()
{
//line1
//line2
//line3
//line4[Exception occurs here]
//line5
//line6
//line7 homepage.Logout();
}
Теперь, если, например, в строке 4 возникает исключение, мое приложение никогда не выйдет из системы [строка 7]. Это приведет к сбою моих дальнейших тестовых случаев, поскольку они не смогут войти в систему, поскольку сеанс пользователя будет активен. Как сделать так, чтобы выход из системы всегда происходил при преждевременном сбое теста?
Я попытался поместить логику выхода в @AfterMethod. Он отлично работает, но лучше ли писать тестовый код в методе конфигурации, таком как @AfterMethod?
Я работаю на C#, но концепция, скорее всего, одинакова для всех языков. В моем случае я использую так называемый тег «TearDown» в своем базовом классе, чтобы отметить один метод, который всегда должен запускаться после теста. Все тесты наследуют этот метод от базового класса и обрабатываются соответствующим образом. В последние годы это работало хорошо, и, насколько мне известно, любая подобная концепция считается передовой практикой.
В псевдокоде:
[TearDown]
public void Cleanup()
{
try
{
Logout();
OtherStuffLikeClosingDriver();
}
catch (Exception ex)
{
Log(ex); // Obviously, this logging function needs to generate logs that are easily readable, based on the given exception.
FinishTest(testInstance, testName); // Handles critical flows that should always be finished (and "should" not be able to error out)
throw ex; // In my case, throwing the exception again makes sure that the exception is shown in the test output directly. This often speeds up the first diagnose of a failed test run.
}
}
Просто не забудьте обработать исключения и тому подобное: логика в вашем @AfterMethod не должна прерываться непредвиденными проблемами.
Выйти из системы в @AfterMethod
было бы неплохо, но убедитесь, что вы делаете это эффективно.
см. ниже код, используя @AfterMethod
@AfterMethod
public void screenShot(ITestResult result){
if (ITestResult.FAILURE==result.getStatus()){
List<WebElement> username = driver.findElement(By.locator); // element which displays if user is logged in
if (!username.isEmpty())
// steps to logout will go here
}
}
}
Другая альтернатива — вы можете использовать TestNG Listener. реализовать ITestListener
в классе и переопределить метод onTestFailure
, как показано ниже
@Override
public void onTestFailure(ITestResult result) {
if (ITestResult.FAILURE==result.getStatus()){
List<WebElement> username = driver.findElement(By.locator); // element which displays if user is logged in
if (!username.isEmpty())
// steps to logout will go here
}
}
}
добавить ниже тег в testng.xml
<listeners>
<listener class-name = "com.pack.listeners.TestListener"/> // your created class name with package which implemented ITestListener
</listeners>
Если я использую тестовый прослушиватель, должен ли мой класс, содержащий мой тестовый пример, расширять класс, реализующий интерфейс ITestListener, а затем переопределять его метод onTestFailure? Это звучит неплохо. Это ты правильно говоришь?
@Rajan, нет, вам следует создать отдельный класс и реализовать ITestListener
в этом классе, который попросит переопределить все нереализованные методы, и вы должны сделать это дополнительно, вы должны написать код выхода из системы в методе onTestFailure
. и, наконец, добавьте этот класс в прослушиватель, как показано в ответе
@Rajan, сошлитесь на этот блог seleniumeasy.com/testng-tutorials/…
Я понимаю вашу точку зрения. Таким образом, в основном в классе, где я буду реализовывать интерфейс iTestListener и определять все его методы, такие как onTestFailure и т. д., мне нужно будет создать объект моего класса HomePage, который имеет функцию выхода, и я буду вызывать эту функцию изнутри метода onTestFailure. И, конечно же, я добавлю этот класс в testng.xml в качестве слушателя. Верно?
@Rajan, да и внутри if (ITestResult.FAILURE==result.getStatus()){
это
В Java используйте «попробуйте поймать наконец» и поместите выход из системы в предложение finally, docs.oracle.com/javase/tutorial/essential/exceptions/…. Хотя использование метода @After будет работать, оно подрывает свою реальную цель, объем его работы должен быть ограничен настройкой и удалением сервисов и ресурсов. связанный с набором тестов, а не с SUT, например WebDriver или источник ExpectedData.