Помогите разобраться с оформлением тестовых сценариев

общие вопросы
,
#1

Тестовый сценарий 6
Предусловие: в корзине пользователя хранятся продукты (проверка мерджа корзин)

  1. Незалогиненным пользователем положить в корзину продукты
  2. Авторизоваться через хедер (форма Sign in)
  3. Перейти на страницу шоппинг карты
    Ожидаемый результат
  4. При логине каунтер корзины показывает правильное количество продуктов (пересчитывается с учётом продуктов, хранившихсчя в корзине)
  5. На странице шоппинг карты в блоке Cart Summary отображаются все продукты (те, что были добавленны ранее + положенные до авторизации)
  6. Subtotal: и Order Total: пересчитываются с учётом цен всех продуктов в корзине

Вопрос такой:тестовый сценарий достаточно поместить в один тестовый класс,а Ожидаемый результат в методы? Но стоит ли тогда после каждого метода убивать драйвер и проходить каждый шаг отдельно чтобы методы остались независимыми?Или если они тесно связаны оставить так:

TemplatePage templatePage;
SignInPage signinPage;
PaymentPage paymentPage;
ShoppingCartPage shoppingCart;

@BeforeClass
public void setUp() throws InterruptedException {
    templatePage = mainPage.goToTemplate("58393");
    templatePage.addToCart("setup");
    backToMainPage();
    templatePage = mainPage.goToTemplate("53995");
    templatePage.addToCart("setup");
    backToMainPage();
}

@Test
public void countOfProductsAndTheirIdMergedCorrectlyTest() throws IOException, InterruptedException {
    templatePage = mainPage.goToTemplate("53265");
    templatePage.addToCart("test");
    backToMainPage();
    templatePage = mainPage.goToTemplate("58701");
    signinPage = templatePage.addToCart("test").goToCheckOutPage();
    paymentPage = signinPage.continueAsUser().authorization();
    shoppingCart = paymentPage.goToShoppingCart();
    Assert.assertTrue(shoppingCart.cartMergeIdAndCount());
}

@Test(priority = 1)
public void orderTotalMergedCorrectlyTest() {
    Assert.assertTrue(shoppingCart.cartMergeOrderTotal());
}

@Test(priority = 2)
public void orderSubtotalMergedCorrectlyTest() {
    Assert.assertTrue(shoppingCart.cartMergeSubtotal());
}

Или лучше сценарий в отдельную xml ?
За неимением опыта не знаю как сделать “грамотно”

и да,Allur отдельную xml воспринимает как тестовый сценарий…

#2

Если для всех ожидаемых результатов шаги выполнения одинаковые, то зачем разделять это на разные тесты (убивать драйвер)? Или я что то не так понял?
З.Ы.: если очень хочется разделить, не всегда нужно убивать каждый раз драйвер, всегда можно сделать в тирдауне логаут и перезагрузить страницу

#3

Не совсем понял связь драйвера и независимости. Небольшой совет - обрабатывать исключения на самом нижнем уровне абстракции, так как вот я смотрю что у вас пара исключений может быть методом брошена, но не понимаю почему.

#4

Если для всех ожидаемых результатов шаги выполнения одинаковые, то зачем разделять это на разные тесты (убивать драйвер)?
Чтобы тесты были не зависимыми.

З.Ы.: если очень хочется разделить
Я не хочу разделять,мне как раз так и видется,но я хочу разобратся как правильно делать

#5

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

#6

Обрабатывать их в любом случае надо, просто перехватив записать в лог и вернуть false который зафейлит тест по ассерту и вы получите что хотели - при исключении тест падает. Всегда думайте что ваш код будет читать другой человек или вы сами через год, вот вы вспомните откуда интерраптед эксепшн? А кстати откуда ошибка прерывания- вы же не тред-слип там юзаете?

#7

Да,есть сред слипы,но максимально минимально )
Например,в форме после ТАБ “секунду” сервак проверяет корректность поля и другие инпуты блокируются,а форма такая что експектед не поставиш,так как все инпуты инвизибл…короче,идём ТАБом.
На счет предложения обрабатывать,прийму,но суть вопроса ушла в другое русло.
**Вопрос такой:тестовый сценарий достаточно поместить в один тестовый класс,а Ожидаемый результат в методы?**Или лучше сценарий в отдельную xml ?
Допускаю,что для некоторых вопрос “глупый”,но меня интересует КАК ПРАВИЛЬНО делать.

#8
  1. Не встречал по опыту ситуаций когда нельзя было кондишены юзать - можно ожидать видимости инпутов, кликабельности чего либо, исчезновения. Короче нужно просто к чему то привязаться и все будет Ок. Тред слип это очень, очень плохо
  2. Не нужно отдельного иксэмэль, делай именно в классе+методы
#9

Ответ принят, но как бы в догонку,почему Тред слип это очень, очень плохо?
Например,инпуты часто сьедают символы,я использую почаровый ввод с сред.слип(300) и проблем нет,а как ето сделать без него?Можно проверять велью и если что перезаписывать…но это,как мне кажется,не оправдано.

И вообще,читал что слипы проблемны из-за своей хардкодовости,но иногда только это простое и безпроблемное решение.
Если сильно ошибаюсь,буду благодарен за развёрнутый ответ.

#10

Если вы возьмете суммарное время тех Thread.sleep, которые расставлены по всему проекту, ровно на столько увеличится total execution time вашего тестового набора.

Помимо этого, сейчас может ваши 300 мс и работают… Но если завтра ваши девелоперы навесят чего-нибудь тяжеловесного на UI / backend, то 300 мс окажется внезапно недостаточно. Вы начнете судорожно искать все слипы и наугад проставлять какое-то новое значение, которое по-прежнему будет являться фиксированным, а не переменным.

Я лично еще не встречал кейса, когда explicit waits могли бы не сработать. Ваш пример с ипутами скорее всего связан с динамичностью самого контрола, который либо валидирует введенное значение on fly, либо влияет на результаты какого-либо поиска. Смею предположить, что это может быть даже какой-нибудь кастомный Select2, с которым, как известно проще всего бороться нативными js обращениями.

В любом случае либо WDWait + ExpectedConditions, либо native js calls прекрасно решают проблему без всяких константных пауз. А вот разница между explicit waits и Thread.sleep - колосальная. Если в первом случае вы указываете интервал ожидания [0; N] (где условие может сработать в любой точке интервала, в зависимости от производительности вашего приложения), то в случае со слипами время всегда = N. Ну и собственно первый вариант относится условным, второй - к безусловным ожиданиям.

2 лайка
#11

спасибо

#12

Кроме вышесказанного просто может браузер затормозить, много процессов в системе оказаться и так далее.
Вот тут почитай Промедление смерти подобно. Использование ожиданий в Selenium — testers little helper

#13

благодарю