Добрый день, коллеги. Может кто подсказать по тестированию реального устройства ios с помощью appium?
Пытаюсь начать тестировать гибридное приложение и не могу получить webview при запуске. В контекстах всегда только один NATIVE_APP.
P.S. тесты написаны на dotnet

Флаг на debug web view выставлен в приложении ?

Не выставлен. Сейчас буду пробовать, спасибо за подсказку.

Ребят, такой вопрос.
Правильно ли писать несколько тестов или каждый тест должен быть в своём классе?
Например, любой позитив и негатив кейс, должны ли они быть объеденины или все же принцип единой ответственности (1 тест = 1 класс)?

1 тест = 1 класс это НЕ принцип единой ответственности. Он ему не противоречит, конечно, но... представь, что у тебя будет хотя бы несколько сотен тестов. Это несколько сотен классов. и ориентироваться в таком уже не очень удобно)
Сразу на вскидку ещё проблема - тестам часто требуются некие предусловия перед их выполнением. Часто эти предусловия совпадают для групп тестов. И в каждом классе для условной группы тестов ты будешь писать одно и то же предусловие. Привет повторение.
Группируй тесты по какому-нибудь удобному для проекта и лично тебя принципу. Тесты на одну сущность, на один контроллер, на одну страницу и т.д. - смотря что тестируешь и что тебе захочется. В процессе придёт понимание как удобнее всего

Классы в тестах нужны для того, чтобы хранить в их объектах какое-то состояние для этих тестов. Это может быть общий набор подготовленных данных, например. Или другой признак, используемый во всех тестах.

Разумеется, из этого следует, что один тест в классе нет смысла держать. Тогда его можно вообще определить в виде функции.

Ну вот мне всю жизнь было удобно тесты разделять на классы, а их группировать по папкам/пакетам
А для избежания повторений выношу методы за рамки одного теста (например функция логин к примеру)

Ведь если 1 тест содержит кучу строк, а таких тестов (похожих но с разным результатом) сотни, то класс привариться в огромное полотно. По крайней мере я от этой логики отталкивался

Про общее состояние, тоже пример. Один тест проверяет функцию логина, а второй валидацию полей. Общего у них лишь страница где это выполняется и общие элементы (но они в классе страницы)

В огромное не превратится. Возвращаемся к моменту дублирования кода - выносишь общие для тестов штуки (а они стопудово будут, и не мало) в отдельные классы. Например, если мы говорим об api-тестах, то логика построения запросов уходит в какой-нибудь класс, условно говоря SomeControllerTester. А из класса с тестами на этот контроллер ты просто вызываешь метод построения запроса и обрабатываешь ответ

Если мы про UI говорим, то там опять-таки есть классическое разделение - классы Page, описывающие страницу, и классы Tests, в которых уже содержатся тесты

Я об этих)

А, с первого прочтения сообщения подумал, что у вас и элементы и тесты в одном классе, brainlag)

Не, в этим все ок, тут вопрос в другом, что тесты конечно похожи и вроде как и логично объединить, но выйдет полотно большое. И в нете нет никакого ответа в плане «как правильно» все же. Ведь можно и так и так.
Юнит тесты пишут все в 1 файле (грубо говоря)
Но и тесты маленькие
А когда тест на 50-60 строк, а потом ещё таких 10...

Для уменьшения портянистости можно, например, отделить ещё один тип классов, условно PageSteps, в котором будут описаны методы взаимодействия со страницей. А можно определять их в самом классе страницы. Например класс LoginPage будет содержать метод login(String login, String password), что позволяет не вызывать из кода тестов три метода, а всего один

Да, такое есть, но... надо подумать короче)
Спасибо в общем)

Пс если есть обратное мнение, был бы не против тоже услышать)

В IDE можно сворачивать методы, переходить к ним при помощи навигации по названию... Уже давно "длинный листинг" не выглядит препятствием для комфортной работы.

Коллеги, может кто-то имеет практику проверки корректности формирования итогового отчёта(документа). Т.е. например проверить что файл выгружается

можно проверить что файл появился в папке для скачивания и что он не нулевого размера. Ну или прям заморочится и пробовать его потом читать/парсить/сверять данные и структуру. В принципе все реализуемо. вопрос ROI

Привет всем! Я только начинаю вкатываться в автоматизацию в стартапе, где тестов пока нет вообще. Тимлид предложил автоматизировать с Cucumber, я начала знакомиться с этим и по-моему это оверкилл, по крайней мере для моей первичной  задачи покрыть юнит тестами веб приложение. Когда cucumber целесообразно использовать? А когда он нафиг не нужен? Какие best practices по работе с этой штукой?