testomat.io управление авто тестамиЕсли не переоткрывать браузер перед тестом, то какие варианты предложите для решения следующих распространенных проблем:
- куки / кеш
- приведение системы в исходное состояние для теста
- внеплановое падение теста и последующее влияние на предыдущий пункт
1 лайк
Это правда требует разработки некоторого механизма, возвращающего AUT в исходное состояние независимо от результатов выполнения теста. И может быть довольно сложной. Ну или во всяком случае сложнее, нежели закрытие браузера. Поэтому с простой реализации с закрытием браузера в конце каждого теста вполне можно начать.
Главное предусмотреть в архитектуре возможность рефакторинга с изменением поведения на использование одного открытого браузера
1 лайк
Извините, я забыл добавить слово “всегда” в предложение “и уж точно не нужно всегда открывать браузер перед каждым методом и закрывать после каждого метода” 
Куки и кеш чистить надо не всегда. В тех случаях, когда надо, а метод deleteAllCookies не срабатывает – перезапустить браузер.
Приведение системы в исходное состояние не всегда требует перезапуска браузера. В подавляющем большинстве случаев просто достаточно перейти на нужную страничку.
Внеплановое падение теста – тоже, надеюсь, случается не всегда 
После падения можно браузер перезапустить, если хочется. Да и то не всегда – как правило опять же достаточно перейти на нужную страницу и всё.
И вообще, следуя этой логике, при ручном тестировании тоже надо после каждого теста перезапускать браузер. Что, все так и делают?
Никогда не видел внятной реализации аппстейтов в рамках webapps-autotesting - поэтому полагаю, что задача далеко не самая тривиальная.
Но на мой взгляд, основная причина схемы new_test->new_browser - параллелизация.
А как нам понять, когда надо чистить, а когда не надо? Порой появляются такие баги, которые надо некоторое время инвестигейтить, чтобы понять, что дело действительно в куках / кеше. Перезапустить браузер в данном случае - гораздо проще, чтобы обезопасить дальнейшие тесты от внезапных фейлов.
Согласен, не всегда. Но что, если мы не можем сделать прямой редирект по URL? В приложении есть баги по дефолту. Что если какой-то баг помешает нам привести систему в нужное состояние для дальнейшего тестирования? К примеру, нам нужно залогиниться под юзером с другими правами, а функционал логаута некорректно работает. Понимаете, к чему я клоню? В данной ситуации все наши последующие тесты становятся dependent от работоспособности логаута, что само по себе неверно. Перезапуск браузера в данном случае снимает подобного рода зависимости. Плюс ко всему, далеко не факт, что приведение системы в исходное состояние после выполнения определенных тестов не займет гораздо больше времени, нежели перезапуск браузера.
Соглашусь с @joemast . Далеко не всегда приведение системы в нужное состояние - является тривиальной задачей. Если тест упал на unexpected шаге, а следующий - способен лишь подхватить выполнение с end state предыдущего, то для хэндла таких ситуаций придется разрабатывать чуть-ли не AI, который сможет четко определить, в каком месте мы сейчас находимся, и как вернуться в исходное состояние. В таких ситуациях, гораздо проще перезапустить браузер, нежели писать умную систему навигации / мониторинга за AUT.
Разница в том, что у человека есть мозг. И если что-то пошло не так, он сам догадается перезапустить браузер. А машина по дефолту не имеет мозгов, и научить ее быть похожей на человека - совсем не задача автоматизации тестирования. К тому же, мы ведь пишем авто-тесты для моделирования действий конечного пользователя. А конечный пользователь в базовых случаях не будет ходить туда-сюда по всем страницам, перезаходить под другими аккаунтами и т.п. Он зайдет в приложение, чтобы воспользоваться каким-то ограниченным набором функционала, и закроет браузер / страницу.
П.С. Я тоже не утверждаю, что перезапускать браузер нужно всегда. Лишь привел примеры, когда при столкновении с определенными проблемами это будет самым простым вариантом решения.
Ну и конечно важен вопрос параллелизации, как заметил @vmaximv.
То есть Вы предпочитаете, чтобы такие баги не были найдены? Стабильность тестов ценнее найденных багов, пусть даже найденных случайно, как косвенный результат?
И я тоже не утверждаю, что его никогда не надо перезапускать. Есть ситуации, когда надо перезапускать? Конечно есть! С чем спорите? Я всего лишь высказал тезис, что аннотации не обязательно должны быть симметричными.
В этом случае должна быть логика “один поток -> один браузер”. С чем, кстати, упомянутая WebDriverFactory отлично справляется.
Кто-то спорит с Алексеем Баранцевым в вопросах теории тестирования ) Забавно, я в школу пошел, когда этот человек начал в QA работать (и Микрософт только через 2 года ввела позицию тестировщика в свой штат). На первой работе уже по его вебинарам учился.
Ничего, ты подрастешь, тоже сможешь спорить
Надеюсь - не понадобится. Я больше практик, чем теоретик
Ну так и поделились бы своими практиками:)
На деле переиспользование браузера между тестами я видел только в случае зависимых тестов либо юнит тестов.
Обычный среднестатистический тест идет от одной до пяти минут, т.е. временем запуска браузера можно пренебречь. Плюс забываем про браузерные мемори-лики и приведением AUT в исходное состояние (в особо запущенных случаях это может занять больше времени, чем сам тест).
Решение лобовое - но довольно жизнеспособное.
Другое дело, если тесты “два притопа два прихлопа” - там другие варианты имеют место быть.
2 лайка
Я большую часть проф. жизни ядра тестирую и API. При чем два последних года - C++. Для меня решение кажется лежит на поверхности - перед началом теста проверять - есть ли бегущие процессы браузера и убивать их. Что-то вроде:
Runtime rt = Runtime.getRuntime();
if (System.getProperty("os.name").toLowerCase().indexOf("windows") > -1)
rt.exec("taskkill " +....);
else
rt.exec("kill -9 " +....);
Ну и я никогда не юзал TestNG, но думаю если заменить @BeforeClass на @BeforeTest, а @AfterSuite на @AfterTest то тоже может работать. Я не смотрел в документацию, просто догадка, даже не знаю какие там методы в TestNG
Тут главный вопрос не том, что я предпочитаю, а в том, что тестируют наши тесты, и какова основная цель автоматизации на проекте. Для поиска случайных багов есть manual QAs, у которых в свою очередь есть глаза и мозг. Повторюсь, мы сейчас обсуждаем не разработку AI, который все умеет и понимает. Всегда хорошо, если наши тесты находят случайные баги. Но если они делают только то, на что запрограммированы, и делают это стабильно и качественно, никто ведь нас не упрекнет за пропуск случайного бага, ибо машина - не человек, а протестировать все - попросту невозможно. Я не из тех, кто считает, что автоматизация способна (и должна) полностью заменить человека.
Думаю, что не стоит продолжать эту тему, ибо она уже выходит за рамки поставленного вопроса.
Никто не спорит. Тут люди делятся своими мыслями и соображениями. 
Если кто-то с кем-то ‘спорит’ - это не значит, что он не уважает его труд и вклад в общее дело. Одно из самых важных качеств тестировщика - подвергать все сомнению (в разумных пределах). Если молча / бездумно со всем соглашаться, не высказывая своей собственной позиции / видения проблемы, то далеко в тестировании не уйти. Впрочем, это касается не только тестирования.
На поверхности все кажется очень простым. А на деле, когда вы начинаете масштабировать ваши тесты, все может оказаться гораздо более сложным. 