t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

Теги: #<Tag:0x00007f7487da25e8> #<Tag:0x00007f7487da2520>

Тестовый сценарий 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 воспринимает как тестовый сценарий…

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

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

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

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

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

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

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

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

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

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

Если вы возьмете суммарное время тех 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 Симпатий

спасибо

Кроме вышесказанного просто может браузер затормозить, много процессов в системе оказаться и так далее.
Вот тут почитай https://testerslittlehelper.wordpress.com/2016/03/25/промедление-смерти-подобно-использо/?frame-nonce=7909bdeed4&preview=true&iframe=true

благодарю