testomat.io управление авто тестамипо одному запускаю из Eclipse и пачкой запускаю из него же.
на данном этапе просто делаю тесты и учусь за одно
все сделала по семинарам господина @barancev
настроила maven, git, jenkins локально
не запускала еще из командной строки
Debug из IDEA/Eclipse заходит в этот метод ?
Debug у меня работет, но всегда доходит до точки остановки и если делаю дальше выполнение по шагам, то всегда Source not found на вкладке Invoker.class
В смысле в метод заходит , но на нем валиться ? И какой browser .
аннотации @AfterTest @AfterClass не пробовали поставить вместо Suite ?
при дебаггинге в метод заходит, но если встречает точку остановки Toggle Breakpoint то никогда не идет дальше по шагам, даже если ошибки никакой нет
если ставлю @AfterTest то никакой разницы не видно и отличий от @AfterSuite
если ставлю @AfterClass то выполняется только один тест, дальше ошибка The FirefoxDriver cannot be used after quit() was called.
запускаю пачкой через package.xml, потому что некоторые тесты в группе "BUG"
в общем классе TestBase два таких метода, только не спрашивайте почему, это из заготовок с семинара 
@BeforeClass
public void init() {
baseUrl = PropertyLoader.loadProperty("site.url");
gridHubUrl = PropertyLoader.loadProperty("grid2.hub");
browser = new Browser();
browser.setName(PropertyLoader.loadProperty("browser.name"));
browser.setVersion(PropertyLoader.loadProperty("browser.version"));
browser.setPlatform(PropertyLoader.loadProperty("browser.platform"));
String username = PropertyLoader.loadProperty("user.username");
String password = PropertyLoader.loadProperty("user.password");
driver = WebDriverFactory.getInstance(gridHubUrl, browser, username, password);
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
driver.manage().window().maximize();
genData = new GenerateData();
}
и
@AfterSuite(alwaysRun = true)
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
на сколько я помню аннотации не работают для group если сами не в группе .
уберите group
А не логичней тогда организовать структуру логина по другому?
Например логиниться перед методом, и переходить на страницу логина и разлогиниваться каждый раз После тестового метода.
Как вариант, для каждого тестового метода, открывать свой браузер и закрывать после себя
1 лайк
@Diana, прислушайся к совету @alexkuzpro - Before и After аннотации должны быть симметричными. То есть, если Before Method, то и After Method - это позволит открывать новый браузер перед запуском теста (метода тестового класса) и закрывать браузер после его выполнения. У меня например сейчас так сделано, нормально работает.
Если надо, чтобы браузер открывался один раз на весь класс тестов и закрывался после его завершения, то и использовать тогда BeforeClass и AfterClass и т.д. Зависит от того как у тебя организованы тесты
Читай документацию, разбирайся, экспериментируй.
1 лайк
Не обязательно аннотации должны быть симметричными. В данном случае перед каждым классом драйвер инициализируется путём обращения к фабрике, но после завершения класса он не останавливается, и следующий класс имеет возможность его повторно использовать. А при завершении сьюта драйвер останавливается (хотя правильнее было бы сделать WebDriverFactory.dismissAll(), если это используется моя реализация фабрики).
И уж точно не нужно открывать браузер перед каждым методом и закрывать после каждого метода, так большая часть времени будет тратиться не на выполнение тестов, а на запуск браузеров.
Если не переоткрывать браузер перед тестом, то какие варианты предложите для решения следующих распространенных проблем:
- куки / кеш
- приведение системы в исходное состояние для теста
- внеплановое падение теста и последующее влияние на предыдущий пункт
1 лайк
Это правда требует разработки некоторого механизма, возвращающего AUT в исходное состояние независимо от результатов выполнения теста. И может быть довольно сложной. Ну или во всяком случае сложнее, нежели закрытие браузера. Поэтому с простой реализации с закрытием браузера в конце каждого теста вполне можно начать.
Главное предусмотреть в архитектуре возможность рефакторинга с изменением поведения на использование одного открытого браузера
1 лайк
Извините, я забыл добавить слово “всегда” в предложение “и уж точно не нужно всегда открывать браузер перед каждым методом и закрывать после каждого метода” 
Куки и кеш чистить надо не всегда. В тех случаях, когда надо, а метод deleteAllCookies не срабатывает – перезапустить браузер.
Приведение системы в исходное состояние не всегда требует перезапуска браузера. В подавляющем большинстве случаев просто достаточно перейти на нужную страничку.
Внеплановое падение теста – тоже, надеюсь, случается не всегда 
После падения можно браузер перезапустить, если хочется. Да и то не всегда – как правило опять же достаточно перейти на нужную страницу и всё.
И вообще, следуя этой логике, при ручном тестировании тоже надо после каждого теста перезапускать браузер. Что, все так и делают?
Никогда не видел внятной реализации аппстейтов в рамках webapps-autotesting - поэтому полагаю, что задача далеко не самая тривиальная.
Но на мой взгляд, основная причина схемы new_test->new_browser - параллелизация.
А как нам понять, когда надо чистить, а когда не надо? Порой появляются такие баги, которые надо некоторое время инвестигейтить, чтобы понять, что дело действительно в куках / кеше. Перезапустить браузер в данном случае - гораздо проще, чтобы обезопасить дальнейшие тесты от внезапных фейлов.
Согласен, не всегда. Но что, если мы не можем сделать прямой редирект по URL? В приложении есть баги по дефолту. Что если какой-то баг помешает нам привести систему в нужное состояние для дальнейшего тестирования? К примеру, нам нужно залогиниться под юзером с другими правами, а функционал логаута некорректно работает. Понимаете, к чему я клоню? В данной ситуации все наши последующие тесты становятся dependent от работоспособности логаута, что само по себе неверно. Перезапуск браузера в данном случае снимает подобного рода зависимости. Плюс ко всему, далеко не факт, что приведение системы в исходное состояние после выполнения определенных тестов не займет гораздо больше времени, нежели перезапуск браузера.
Соглашусь с @joemast . Далеко не всегда приведение системы в нужное состояние - является тривиальной задачей. Если тест упал на unexpected шаге, а следующий - способен лишь подхватить выполнение с end state предыдущего, то для хэндла таких ситуаций придется разрабатывать чуть-ли не AI, который сможет четко определить, в каком месте мы сейчас находимся, и как вернуться в исходное состояние. В таких ситуациях, гораздо проще перезапустить браузер, нежели писать умную систему навигации / мониторинга за AUT.
Разница в том, что у человека есть мозг. И если что-то пошло не так, он сам догадается перезапустить браузер. А машина по дефолту не имеет мозгов, и научить ее быть похожей на человека - совсем не задача автоматизации тестирования. К тому же, мы ведь пишем авто-тесты для моделирования действий конечного пользователя. А конечный пользователь в базовых случаях не будет ходить туда-сюда по всем страницам, перезаходить под другими аккаунтами и т.п. Он зайдет в приложение, чтобы воспользоваться каким-то ограниченным набором функционала, и закроет браузер / страницу.
П.С. Я тоже не утверждаю, что перезапускать браузер нужно всегда. Лишь привел примеры, когда при столкновении с определенными проблемами это будет самым простым вариантом решения.
Ну и конечно важен вопрос параллелизации, как заметил @vmaximv.
То есть Вы предпочитаете, чтобы такие баги не были найдены? Стабильность тестов ценнее найденных багов, пусть даже найденных случайно, как косвенный результат?
И я тоже не утверждаю, что его никогда не надо перезапускать. Есть ситуации, когда надо перезапускать? Конечно есть! С чем спорите? Я всего лишь высказал тезис, что аннотации не обязательно должны быть симметричными.
В этом случае должна быть логика “один поток -> один браузер”. С чем, кстати, упомянутая WebDriverFactory отлично справляется.
Кто-то спорит с Алексеем Баранцевым в вопросах теории тестирования ) Забавно, я в школу пошел, когда этот человек начал в QA работать (и Микрософт только через 2 года ввела позицию тестировщика в свой штат). На первой работе уже по его вебинарам учился.
Ничего, ты подрастешь, тоже сможешь спорить
Надеюсь - не понадобится. Я больше практик, чем теоретик