Комментарии 14
У нас тесты разделены по уровням:
1. Тестовый уровень
2. Бизнес логика
3. Низкий уровень
Соответственно верхний уровень отвечает только за тестовый сценарий (тестовые данные, последовательность шагов, проверки). Этот уровень вызывает готовые блоки бизнес логики. Начинающие тестировщики автоматизаторы работают здесь.
Бизнес уровень — реализует продуктовую логику (например логин, добавление комментария, получение списка комментариев). Те кто хорошо разобрался с тестовым уровнем продолжают работать здесь. Этот уровень вызывает низкий уровень оберток.
Низкий уровень — обертки над Selenium, RestClient и прочее — необходимое для тестов. Здесь соответственно уже работают эксперты.
За счет такого разделения получается довольно быстро обучить тестировщиков автоматизации. Само собой на Confluence имеются подробные статьи по типовым задачам.
1. Тестовый уровень
2. Бизнес логика
3. Низкий уровень
Соответственно верхний уровень отвечает только за тестовый сценарий (тестовые данные, последовательность шагов, проверки). Этот уровень вызывает готовые блоки бизнес логики. Начинающие тестировщики автоматизаторы работают здесь.
Бизнес уровень — реализует продуктовую логику (например логин, добавление комментария, получение списка комментариев). Те кто хорошо разобрался с тестовым уровнем продолжают работать здесь. Этот уровень вызывает низкий уровень оберток.
Низкий уровень — обертки над Selenium, RestClient и прочее — необходимое для тестов. Здесь соответственно уже работают эксперты.
За счет такого разделения получается довольно быстро обучить тестировщиков автоматизации. Само собой на Confluence имеются подробные статьи по типовым задачам.
НЛО прилетело и опубликовало эту надпись здесь
Xpath — зачем грузить мануальщиков такими громоздкими конструкциями?.. намного удобные методы поиска элементов вроде .closest(), parent(), filter(), поиск внутри коллекции $$, chaining и прочие
Сложные условия не станут проще, а знания будут менее универсальны.
Более широкое использование форматных строк и констант проблему громоздкости сильно уменьшает.
почему просто не добавить уникальные id для элементов на странице?
Если это не нужно для работы приложения, адекватна ли польза зашиванию тесто-специфичного контента? Не говоря уже о растущей сложности логики по генерации id для динамических элементов.
НЛО прилетело и опубликовало эту надпись здесь
Бест практис в современном фронт-енде — избегать id.
Внедрять тестовую оснастку в основной код приложения — это плохая практика. Больше бессмысленного шума в коде!
Делать это ниндзя-коммитами от тестеров — тоже плохая практика. Нужно больше конфликтов и тестов, прибитых id-гвоздями, за консистентностью и непротиворечивостью которых нужно отдльно следить!
Выпиливать тестовую оснастку на этапе сборки — это вообще чудесно!
Внедрять тестовую оснастку в основной код приложения — это плохая практика. Больше бессмысленного шума в коде!
Делать это ниндзя-коммитами от тестеров — тоже плохая практика. Нужно больше конфликтов и тестов, прибитых id-гвоздями, за консистентностью и непротиворечивостью которых нужно отдльно следить!
Выпиливать тестовую оснастку на этапе сборки — это вообще чудесно!
НЛО прилетело и опубликовало эту надпись здесь
Представте БЭМ, где под каждый блок свой PageObject, тогда навигация будет максимум трехступенчатой (родитель-блок-элемент), а тесты будут обваливаться только при серьезном рефакторинге блока, что закономерно и не больно.
Просто добавление кнопки рядом не сломает селектор.
Ну куда ж без классов?) Главное, чтобы не автотестеры их расставляли.
добавили кнопочку на форму и вот тот xpath из статьи стал невалиден
Просто добавление кнопки рядом не сломает селектор.
Может вам хотя бы классы по душе, раз ID это плохо?
Ну куда ж без классов?) Главное, чтобы не автотестеры их расставляли.
Приходите поболтать www.meetup.com/WrikeTechClub/events/265526316
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Снова в школу: как обучить ручных тестировщиков разбираться с автотестами