Содержание
Но ни разу не видели случая, когда ценность умного подхода компенсировала бы созданную им сложность. В автоматизации тестирования, как и в общей разработке программного обеспечения, избегайте излишне умных подходов. Например, при создании копии объектов страниц (new ItemDetailPage() ) вы можете сделать требованием, чтобы при создании копии объекта проверялось, что браузер находится на ожидаемой странице. Таким образом, конструктор ItemDetailPage будет искать и проверять некоторый элемент или заголовок страницы. Это позволяет тестам «быстро падать», когда что-то идет не так, даже без явного assertion-а на уровне теста. Эта схема добавления прослойки между объектами страницы и тестами на самом деле довольно распространена.
Вместо этого просто верните состояние и позвольте тесту определить, что оно означает. Целью POM классов является установка и получение состояния вашего приложения.Так что вам понадобятся соответствующие методы для этого. В большом проекте много страниц и они связаны между собой, для того чтобы выполнять переход добавим следующий шаг в default метод класса RegistrationPage — LoginPage.new.
Данный шаблон проектирования помогает инкапсулировать работу с отдельными элементами страницы, что позволяет уменьшить количество кода и упростить его поддержку. Если, к примеру, дизайн одной из страниц изменён, то нам нужно будет переписать только соответствующий класс, описывающий эту страницу. Данный шаблон проектирования помогает инкапсулировать работу с отдельными элементами страницы, что позволяет уменьшить количество кода и его поддержку. В абстрактный класс BasePage вы выносите методы, которые дублируются у вас на страницах, например метод клик, который вы хотите переписать с умным ожиданием. Вторая реализация с использованием объекта accountDescriptor создает более высокую связанность между классом теста и классом объекта страницы. Хотя сбор одинаковых вещей, которые изменяются вместе, является целью любого проектирования программного обеспечения, эта стратегия заходит слишком далеко.
Приемочные тесты / Фича спеки
Акторы объединяют действия между объектами страницы, чтобы представить эти общие агрегированные действия на страницах в виде многократно используемых фрагментов. Они обеспечивают интерфейс более высокого уровня для тестов. Таким образом, каждому тесту не нужно заново реализовывать эту последовательность, он просто использует интерфейс, предоставляемый актором. Этот пример может выглядеть простым и легко читаемым, но это всего лишь несколько основных шагов. В реальном user journey тесте, которое использует объекты страницы, раскрывающие столь детальный интерфейс, могут быть сотни отдельных шагов.
- Я думаю, что спецификации, связанные с UI, часто не получают обьектно ореинтированного подхода, который им нужен.
- Для простоты понимания пример ниже не использует фреймворк.
- В этом примере страница FrenchSearchResultsPage будет наследоваться от BaseSearchResultsPage.
- Подобные бездумные шаги могут привести к абсолютно ненужному усложнению кода и костыльным решениям.
- Внутренний тест-фреймворк моей компании должен поддерживать различные типы компонентов сайта.
Этот метод может принимать аргументы, чтобы дать тесту немного больше контроля, но идея понятна. В противном случае они являются просто раздутыми страничными объектами. Это понимание паттернов проектирования не диктует каждую деталь ваших страничных объектов. Вот почему автоматизация тестирования требует критического и творческого мышления, свойственного разработке программного обеспечения, и не является шаблонной.
Page Factory
Большинство статей по паттернам – весьма абстрактны, это верно. Для того, чтобы понять, как их применять https://deveducation.com/ именно в test automation, не достаточно лишь прочитать определения и парочку примеров.
В нем вся функциональность определенного веб-UI оборачивается в класс. Это хорошо для простых просмотров, где нет особых возможностей для взаимодействия – page object ясны и хорошо управляемы. В случае входа в систему LoginPage может иметь ссылку на данные, созданные в методе BeforeSuite или BeforeEach и сохраненные в глобальном хранилище «текущей информации о пользователе» для последующего использования. Это может показаться выгодным, но все равно перегружает ответственность объекта страницы. На практике такое использование наследования не добавляет значительной ценности, кроме доказательства того, что автоматизатору нравится использовать наследование. Того же результата можно было бы достичь, используя компоненты страницы и простую композицию, или просто допустив минимальное дублирование на страницах, специфичных для каждого языка.
— централизованно обрабатывать эксепшены для каких-то экшенов (что актуально для Selenium, когда тебе нужно дождаться какого-либо изменения на странице и только потом идти дальше). Разработку программного обеспечения легко изучить, но трудно освоить, и это часть того, что делает ее такой увлекательной. Строка ShopperActor.logonAndSelectItem(); говорит мне именно то, что мне нужно знать, чтобы понять, что делает тест.
Любой из тестов принимает на вход фикстуру App, которая возвращает приложение с драйвером и всеми параметрами – в его контексте вы выполняете нужные вам тесты. Никто вам не мешает вызвать несколько инстансов приложения – хоть 100 (к вопросу о параллельности), зависит только от реализации возвращения Арр – контекста. Этот топик о том как мы тестируем веб-интерфейс нашего продукта Plus1 WapStart. Этот паттерн имеет много общего с реальными задачами и позволяет писать автотесты простыми для чтения и понимания.
Паттерн Page Objects в Ruby для пользователей Capybara
В основном вы можете не открывать браузер самостоятельно, чтобы тестировать этот материал вручную большую часть времени, что не только менее изящно, но и намного более трудоемко и подвержено ошибкам. Без этого инструмента процесс «наружного тестирования», который вы передадите из высокоуровневых тестов в свои юнит тесты, будет намного более болезненным и, возможно, поэтому будет автоматизация тестирования при разработке продукта игнорироваться. Вместо доступа к функциям через страницу это можно делать через компоненты. MobileLoginDecorator переписывает базовую функциональность логина новым классом, специфичным для мобильных устройств. Он тоже просто выводит “Mobile login” в командную строку – это сделано, чтобы сократить пример. BasicLoginComponent содержит конкретное внедрение метода логина.
Очевидно что паттерн можно реализовать и с селениумом и с девтулзами и с playwright, и он не зависит от технологии. Этот паттерн как раз и решает много проблем пейдж обжекта, с его большими наследованиями, организацией кода, дублируемости, и читаемость тестов. Это зависит от характера вашего приложения и даже от языка, на котором реализована ваша автоматизация. Хотя такой подход может показаться полезным, это создает раздутые объекты страниц и превращает BasePageObject в God Object. Сделайте это, и ваша архитектура сделает код многократно используемым, читаемым, с низкой связностью и т.д. Делайте это снова и снова, и вы увидите, как возникает один и тот же набор паттернов, которые называются паттернами проектирования.
Все наши выверты в построении архитектуры для тестов делаются не только для того, чтобы уменьшить дублирование кода, мы инкапсулируем логику в классах по целям, для которых они создаются. Сейчас вы не понимаете данный уровень абстракции, потому что он вам не особо нужен и это нормально, но мы должны помнить, что класс должен делать/уметь/знать лишь то что ему нужно. Плюс хочу сказать что есть и более высокие уровни абстракции в построении тестов, но они могут быть вам не нужны. @evgmoskalenko, вот у вас в строке googleHomePage().openPage().searchFor(“qa automation framework”); например, новый объект new googleHomePage() указывается без ключевого слова new. Я указываю у себя создание объекта явно с использованием new. Конструктор LoginPage получает копию класса LoginData и использует ее в методе логина.
Методы
Фича спеки, с другой стороны, немного уровнем ниже в тестовой пищевой цепи. Более высокий уровень, чем модульные тесты, которые сосредоточены на технических деталях и бизнес-логике ваших моделей, фича спеки описывают поведение на странице и между ними. Это решение вновь требует большего количества классов, но в каждом из них меньше кода, и их проще понимать и поддерживать. Их также легко использовать повторно, если они встречаются на нескольких страницах. Мы хотим вставить функциональность логина в UI-тест простого сайта. Однако мы хотим хранить имя пользователя и пароль напрямую в классе, чтобы не передавать их каждый раз, когда требуется авторизация.
Selenium Webdriver
Не уникальные выносятся в файл/модуль страниц, откуда потом импортируются. Начнем с того что page object – это уже некий паттерн. Второе, паттерны, уместны тогда, когда система, которую они описывают, является прозрачной и однозначной для описания, а не “живой и не состоявшейся”. Для чекбокс-элементов (или других переключателей) простое нажатие на них может не соответствовать желаемому замыслу теста.
Люди, более знакомые с TDD, ничего не упустят, если пропустят эту часть. Если вы будете придерживаться этого принципа, вы быстрее завершите разработку фреймворка, потому что вам не нужно будет думать о всех возможных вариантах до внедрения. К тому же вы можете по запросу создавать необходимые инструменты вместо разработки готового решения, которое может быть сложным и перегруженным. Здесь отсутствует лишь тест-класс, использующий оба набора данных авторизации. Теперь можно изменить класс WebshopPage, чтобы он использовал фабрику для возвращения своих компонентов. Класс SearchBar должен содержать только метод поиска.
Это во многом зависит от архитектуры и дизайна вашего конкретного веб-приложения. UI-фреймворки, такие как React, организованы вокруг многократно используемых компонентов, поэтому часто это отличная отправная точка. Многие люди думают о паттернах проектирования не так.
Повторное использование интерфейса — разделение «что» и «как»
Централизованные локаторы чаще всего создают больше сложностей, чем того стоят. Более реалистичный, но не менее коварный пример — когда объекты страницы обращаются к какому-либо типу глобального состояния, чтобы получить тестовые данные (данные для входа в систему и т.д.). Объект страницы не решает напрямую, что делать, но он «звонит другу», чтобы получить эту информацию. Еще один распространенный, но часто сомнительный пример наследования в классах объектов страниц — создание базовых классов для страниц, которые очень похожи, но имеют разные локаторы. Например, страница SearchResultsPage, которая была локализована на английский, французский и немецкий языки. Мы видели несколько умных применений наследования в дизайне страничных объектов.
Recent Comments