Кто-то знает "лучшие практики" проверок локаций в играх с открытым миром?

Кто-то знает "лучшие практики" проверок локаций в играх с открытым миром?

Есть вариант что ребята из этого чата https://t.me/qa_gamedev

Есть вариант что ребята из этого чата https://t.me/qa_gamedev

Спасибо!!!

нп)

всем доброго! начал изучать Selenium,возник вопрос с прокликиванием всех пунктов меню,включая вложенные пункты (driver.findElements(By...) , element.click() и проч). Проблема в том,что id - шники элементов "протухают" после клика по первой же ссылке,соответственно вываливается исключение StaleElementReferenceException. Можно,конечно,каждый раз после клика по очередному пункту меню делать искать уже найденные элементы всего меню заново,но это как-то костыльно. Хочется один раз взять все нужные элементы и работать с ними. Это возможно? Какие еще есть варианты?

Пользоваться Selenide. С ним не протухают.

С Selenium надо заново переискивать.

это возможно, нужно всего-то описать методы страницы, где в каждом экшене (например, type_email()) будет поиск по DOM'у. В самих же тестах все будет чисто . p.s. работает на любом языке, без необходимости тащить Джаву, если для вас критично оставаться как можно проще в наборе технологий.

Загугли PageObject паттерн

Добрый вечер.Ребят,есть ли у кого хороший простой пример реализации паттерна Page Object на пример тестирования web страницы .Я что то никак не могу понять,что делаю не так.Послала вариант сделанного задания на вакансию ароматизаторов мне отказали,сказали что плохо сделано.Нахожк много примеров в инете,но все какие то запутанные.

Добрый вечер.Ребят,есть ли у кого хороший простой пример реализации паттерна Page Object на пример тестирования web страницы .Я что то никак не могу понять,что делаю не так.Послала вариант сделанного задания на вакансию ароматизаторов мне отказали,сказали что плохо сделано.Нахожк много примеров в инете,но все какие то запутанные.

А для каких целей используете PageObject?

Можете запостить в github ваш вариант, оценим.

Вот:https://github.com/VikaDevTemp/temp

Буду рада,если поможет мне разобраться

локаторы просто огонь

а в тестах try/catch щас практиуется?

ну есть кое-какие недостатки

Можно глянуть например вот этот код: https://github.com/vinogradoff/QaBattle-typed-vs-untyped/tree/master/src/test/java/imdb на Selenide, правда

а в тестах try/catch щас практиуется?

ничего фатального в try-catсh блоке нет, но всё подряд туда запихивать, конечно же, не надо.

по самому тесту: https://github.com/VikaDevTemp/temp/blob/master/YandexAlureWorkExampleTemp/src/test/java/com/pflb/learning/tests/YandexPageTest.java

забыли добавить проверку

посмотрите локаторы, можно лучше реализовать их

А вы у собеседующих не спрашивали, на что вам нужно обратить внимание?

так же, я вижу метод @AfterClass //Аннотация Junit. Говорит, что метод должен запускаться каждый раз после всех тестов public static void tearDown() { DriverManager.getDriver().quit(); } а setUp не могу найти :(

так же, я вижу метод @AfterClass //Аннотация Junit. Говорит, что метод должен запускаться каждый раз после всех тестов public static void tearDown() { DriverManager.getDriver().quit(); } а setUp не могу найти :(

Там все сидит в new YandexMainPage() =)

а, эвоно как

Так а что с чатом для начинающих тестировщиков? Есть ссылочка?

https://t.me/qajuniors

так же, я вижу метод @AfterClass //Аннотация Junit. Говорит, что метод должен запускаться каждый раз после всех тестов public static void tearDown() { DriverManager.getDriver().quit(); } а setUp не могу найти :(

бесполезный комментарий в коде, кстати, я бы не пушил такие комментарии в общий git. в рамках самообучения - неплохо.

бесполезный комментарий в коде, кстати, я бы не пушил такие комментарии в общий git. в рамках самообучения - неплохо.

комментарии очевидные избыточны

Буду рада,если поможет мне разобраться

@FindBy(xpath = ".//*[@id='glf-pricefrom-var']") //найти по xpath - тут ясно надо по id искать public class YandexNotebooksPage extends AbstractPage { private WebDriver driver; private WebDriverWait wait; оно же у всех страниц общее, явно просится в AbstractPage public void checkTitlePage() { WebElement realTitlePage = driver.findElement(By.xpath("html/body/div[1]/div[3]/div[2]/div[2]/h1")); //найдем элемент микшируем фабрику и локаторы в коде. Зачем? * Данный метод временно не тестируется */ public void countFindNotebooksOnPayge(){ а зачем он тогда в коде? try { //Переходим на вкладку Маркет yandexMarketPage = yandexMainPage.goToMarket(); } catch (NullPointerException e) { а если ошибка вывалилась, мы продолжим тест. Зачем и что мы ожидаем? а на какую позицию задание?

@FindBy(xpath = ".//*[@id='glf-pricefrom-var']") //найти по xpath - тут ясно надо по id искать public class YandexNotebooksPage extends AbstractPage { private WebDriver driver; private WebDriverWait wait; оно же у всех страниц общее, явно просится в AbstractPage public void checkTitlePage() { WebElement realTitlePage = driver.findElement(By.xpath("html/body/div[1]/div[3]/div[2]/div[2]/h1")); //найдем элемент микшируем фабрику и локаторы в коде. Зачем? * Данный метод временно не тестируется */ public void countFindNotebooksOnPayge(){ а зачем он тогда в коде? try { //Переходим на вкладку Маркет yandexMarketPage = yandexMainPage.goToMarket(); } catch (NullPointerException e) { а если ошибка вывалилась, мы продолжим тест. Зачем и что мы ожидаем? а на какую позицию задание?

адище

Коллеги, а какие инструменты вы используете для автоматизации мобилок? Очевидны appium, xamarin, java или ruby/calabash. А что еще реально используется?

espresso, UIautomator

Нативные инструменты ещё

А в каком случае лучше пользоваться нативными? Когда проект про одну платформу?

Кстати, я правильно понимаю, что после ios 10 uiautomation умер, и его заменил xcuitest?

насколько востребовано фронт энд тестирование с использованием selenium?

фронт энд - имеется ввиду только интерфейс и отображение%

?

selenium это всё-таки про e2e

да интерфейс, эмуляция действий пользователя

ну это типо твой инструмент - ты можешь сократить ручную работу и ускориться

как минимум

это факт, но вот если по работе смотреть, то этого мало. если автоматизатор требуется то надо селениум лишь как один из тулзов. в основном еще бекэнд логику надо уметь тестить

бекенд логика может тестироваться и через UI

но в любом случае UI тесты очень медленные

Есть разные уровни тестирования, для них используются разные инструменты. Для e2e и UI - селениум почти что монополист.

бекенд логика может тестироваться и через UI

Может... Но на это есть Юнит тесты

разве юнит тесты - не про код?

Как раз про back и про код

ERROR: S client not available

бекенд и код - помоему это очень разное

хотя если речь про неотделяемый от фронта бекенд - тогда наверно да, юнит тесты

Может... Но на это есть Юнит тесты

нет, юнит-тесты не тестируют бизнес-логику приложений

Формально, юнит-тесты будут тестировать то, что вы им скажете тестировать.

Это ж бездушная машина, что с неё взять.

Формально, юнит-тесты будут тестировать то, что вы им скажете тестировать.

это да

Шу, ну насмотрилсь уже на юнит-тесты в проектах с покрытием в 95%, но ничего не тестирующие вообще.

бекенд и код - помоему это очень разное

Если вы имеете в виду бэк-энд одминки всякие то туда же и селениумом можно подлезть очень просто так же как и фронт-энд

Коллеги, давайте в понятиях определимся сначала, а потом уже будем дискутировать

Согласен

Шу, ну насмотрилсь уже на юнит-тесты в проектах с покрытием в 95%, но ничего не тестирующие вообще.

Я и не утверждал ничего, что бы этому противоречило.

Если вы имеете в виду бэк-энд одминки всякие то туда же и селениумом можно подлезть очень просто так же как и фронт-энд

У вас есть изолированная от UI бэкенд бизнес-логика, представляющая собой цепочку последовательных вызовов бэкенд-компонент A, B и C передающих между собой сущность F в определенном положении стейт-машины. Является ли наличие юнит-тестов на компоненты А, B и C достаточным основанием утверждать, что вся цепочка работает корректно?

такой кейс: юзер нажимает кнопку, ему на почту приходит ссылка. Как будем крыть? 1. UI селениумом, в том числе через UI зайти в почту, кликнуть на письмо, проверить ссылку. 2. UI селениумом, почту через почтовый протокол. 3. UI селениумом, почту проверим дернув логи с нашего сервера на предмет ушло ли письмо юзеру. 4 еще варианты?

(гифка с поездом и шлагбаумами)

Я бы декомпозировал этот тест на несколько, т.к. очевидно тут несколько объектов тестирования.

что из этого будем считать бэкендом, что фронтом

если UI и зайти в почту, то это уже тестируется почта

если UI и зайти в почту, то это уже тестируется почта

да, это уже не наша зона ответственности по идее

но так тоже можно проверить - например можно желать красивое отображение вашего письма и сделать для этого скрин в тесте

хозяин барин

на самом деле я бы тоже разделил уровни

и кнопку, и запрос, если его можно выдернуть

но есть ли смысл?

какой из вариантов наиболее оптимальный? тест на сервере надо покрывать юнит тестом имх. а вот по пользователю оптимально имх вариант 2

соглашусь за 2 вариант