Всем привет. В преддверии старта курса «Python QA Engineer» подготовили перевод еще одного интересного материала.
Большая часть успеха ваших проектов по автоматизации заключается в переиспользовании известных паттернов тестирования, которые, как уже доказано, помогают повысить надежность сценариев автоматизации.
Паттерн проектирования автоматизированного тестирования – это то простое решение, которое день ото дня доказывает миру свою эффективность. Эти шаблоны также считаются лучшими практиками для любого проекта, построенного за счет объектно-ориентированного программирования.
Почему паттерны проектирования так важны для автоматизированного тестирования?
Примите как данность то, что ваши приложения будут изменяться с течением времени.
И поскольку вы знаете, что изменения произойдут так или иначе, вам с самого начала следует использовать лучшие практики и паттерны проектирования. Они сделают ваши тесты переиспользуемыми и их будет легче поддерживать.
Вот несколько распространенных паттернов проектирования автоматизированного тестирования, которые используют многие команды для создания надежной автоматизации тестирования и улучшения всей логики тестирования.
Пример Page Object Николая Адволодкина из Automation Guild 2017
Одной из популярных стратегий, используемых при автоматизации тестирования, является моделирование поведения вашего приложения.
Для этого можно использовать простые page objects, которые моделируют те части программного обеспечения, которые вы тестируете.
Например, вы можете написать page object для страницы входа в систему или домашней страницы. Такой подход правильно отражает принцип единой ответственности.
Если что-то меняется, скажем, ID элемента, то нужно будет изменить всего лишь одно место в коде, а все тесты, использующие этот page object, автоматически получат это изменение без лишних действий. Код теста должен обновляться только в одном месте. Такой подход также помогает уменьшить дублирование кода.
Page objects также скрывают технические детали HTML и CSS за методами с простыми и понятными именами.
Внимательное отношение к именованию ваших методов имеет дополнительное преимущество, поскольку помогает создавать приятный читаемый программный интерфейс приложения (API), которым может быстро начать пользоваться менее технически подкованный программист.
Этот паттерн также придерживается популярной практики разработки программного обеспечения DRY (Don’t Repeat Yourself, не повторяйтесь).
В основном принцип DRY означает, что за каждую часть логики должен отвечать один кусок кода и не более. Дублирование в коде затрудняет его поддержку; чем меньше кода вы пишете, тем лучше, так как больше поддерживаемого кода означает больше шансов, что в ваш фреймворк для тестирования закрадется ошибка.
Один этот шаблон проектирования программного обеспечения сможет с легкостью решить основную часть ваших проблем при тестировании, однако он тоже не панацея. Тем не менее, он позволит вам сделать большой шаг вперед, сделав ваши автоматизированные функциональные тесты более стабильными.
Некоторые инженеры-тестировщики утверждают, что паттерн Page Object часто нарушает принцип, согласно которому, класс должен иметь только одну причину для изменения.
Чтобы избежать этого, многие обращаются к сценарию, который впервые был описан Энтони Маркано (
Page objects – это хороший способ начать делать ваши тесты поддерживаемыми, но если вы не будете вести себя осторожно, они все равно могут со временем выйти из-под контроля.
Паттерн Screenplay (некогда известный как паттерн Journey) представляет из себя применение принципов проектирования SOLID для автоматизированного приемочного тестирования и помогает командам решать эти проблемы. То есть, по сути, это то, что было результатом безжалостного рефакторинга Page Objects с использованием принципов проектирования SOLID.
Паттерн Screenplay берет page objects и разбивает их на действительно крошечные кусочки. Некоторые тестировщики говорят о том, что это сделало их тесты более ремонтопригодными и надежными.
Еще одним существенным преимуществом является то, что он делает тестовые сценарии более удобочитаемыми.
Впервые я услышал про паттерн Screenplay на Automation Guild Session в 2017 году от Джона Смарта (
Screenplay использует идею актеров, задач и целей для формального описания тестов, отказываясь от терминов взаимодействия с системой. В Screenplay вы описываете тесты в терминах актера, у которого есть цели.
Вот пример:
Пример реализации паттерна Screenplay из Automation Guild Session 2017 от Джона Смарта
На первый взгляд может показаться, что использовать этот паттерн гораздо сложнее, чем тот же Page Objects, однако Джон упомянул, что использование этого подхода экономит командам, с которыми он работал, много времени за счет уменьшения затрат на обслуживание и поддержку.
Архитектура портов и адаптеров направлена на то, чтобы убедиться, что вы используете принцип единой ответственности, то есть конкретный объект должен делать что-то одно и иметь только одну причину для изменения.
Когда вы применяете его при автоматизации, убедитесь, что вы отделили код тест-кейса от всего остального, чтобы иметь возможность менять местами медленные компоненты и быстрые симуляторы, тем самым позволяя запускать тест и тестируемое приложение в одном процессе.
Избавьтесь от сетей и интерфейсов ввода/вывода, чтобы ничего не замедляло работу тестового набора. Конечно, сделать это нелегко, но чем больше вы будете к этому стремиться при создании автоматизации пользовательского интерфейса, тем лучше это будет для вас.
Я узнал об этом паттерне во время интервью с создателем Cucumber, Аслаком Хеллесоем (
Аслак также порекомендовал ресурс, который называется Todo-subsecond, который я добавил в свой пост Top Resource for Test Automation Engineers. Это крошечное приложение с full-stack приемочными тестами, которые могут выполняться за миллисекунды. Его цель заключается в том, чтобы проиллюстрировать основные методы достижения этого в любой системе. Прорешав серию упражнений, вы познакомитесь с особым способом реализации test-driven и behavior-driven разработки.
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD).
Впервые я узнал об этом паттерне из интервью с Сэб Роуз
Он говорил о том, что если вы нарисуете паттерн MVC в виде блоков и стрелок, то увидите, что представление, которое является вашим пользовательским интерфейсом, имеет четко определенные связи с моделью и контроллером. Если вы в рантайме можете заменить их моделями и контроллерами, которые создает и контролирует ваш тест, тогда не останется причин, по которым вы не сможете проверить, что пользовательский интерфейс ведет себя не так, как вы хотите.
Также вы можете настроить свою модель и контроллер так, чтобы они имитировали все виды странного поведения, например, выход сети из строя.
Я написал эту статью много месяцев назад, но так и не опубликовал ее.
Я был уверен в своем списке, до того момента, как я поговорил с Сереттой Гамба, автором новой книги A Journey through Test Automation Patterns, где она и ее соавтор Дороти Грэхем рассказывают о 86 паттернах!
Они разбивают паттерны на четыре отдельные категории: паттерны процессов, паттерны управления, паттерны проектирования и паттерны выполнения.
Те, что я описал, относятся к шаблонам проектирования, но существует множество других паттернов, которые решают проблемы, связанные не только с кодом.
Например, есть паттерны, которые касаются плохой корпоративной культуры и моделей управления, которые, по моему опыту, как правило, сводят на нет все усилия по автоматизации тестирования.
Чтобы ознакомиться с полным списком, загляните в wiki по вопросам паттернов проектирования или закажите себе книгу с Amazon.
Узнать подробнее о курсе.
Большая часть успеха ваших проектов по автоматизации заключается в переиспользовании известных паттернов тестирования, которые, как уже доказано, помогают повысить надежность сценариев автоматизации.
Паттерн проектирования автоматизированного тестирования – это то простое решение, которое день ото дня доказывает миру свою эффективность. Эти шаблоны также считаются лучшими практиками для любого проекта, построенного за счет объектно-ориентированного программирования.
Почему паттерны проектирования так важны для автоматизированного тестирования?
Примите как данность то, что ваши приложения будут изменяться с течением времени.
И поскольку вы знаете, что изменения произойдут так или иначе, вам с самого начала следует использовать лучшие практики и паттерны проектирования. Они сделают ваши тесты переиспользуемыми и их будет легче поддерживать.
Вот несколько распространенных паттернов проектирования автоматизированного тестирования, которые используют многие команды для создания надежной автоматизации тестирования и улучшения всей логики тестирования.
Page Objects
Пример Page Object Николая Адволодкина из Automation Guild 2017
Одной из популярных стратегий, используемых при автоматизации тестирования, является моделирование поведения вашего приложения.
Для этого можно использовать простые page objects, которые моделируют те части программного обеспечения, которые вы тестируете.
Например, вы можете написать page object для страницы входа в систему или домашней страницы. Такой подход правильно отражает принцип единой ответственности.
Если что-то меняется, скажем, ID элемента, то нужно будет изменить всего лишь одно место в коде, а все тесты, использующие этот page object, автоматически получат это изменение без лишних действий. Код теста должен обновляться только в одном месте. Такой подход также помогает уменьшить дублирование кода.
Page objects также скрывают технические детали HTML и CSS за методами с простыми и понятными именами.
Внимательное отношение к именованию ваших методов имеет дополнительное преимущество, поскольку помогает создавать приятный читаемый программный интерфейс приложения (API), которым может быстро начать пользоваться менее технически подкованный программист.
Этот паттерн также придерживается популярной практики разработки программного обеспечения DRY (Don’t Repeat Yourself, не повторяйтесь).
В основном принцип DRY означает, что за каждую часть логики должен отвечать один кусок кода и не более. Дублирование в коде затрудняет его поддержку; чем меньше кода вы пишете, тем лучше, так как больше поддерживаемого кода означает больше шансов, что в ваш фреймворк для тестирования закрадется ошибка.
Один этот шаблон проектирования программного обеспечения сможет с легкостью решить основную часть ваших проблем при тестировании, однако он тоже не панацея. Тем не менее, он позволит вам сделать большой шаг вперед, сделав ваши автоматизированные функциональные тесты более стабильными.
Некоторые инженеры-тестировщики утверждают, что паттерн Page Object часто нарушает принцип, согласно которому, класс должен иметь только одну причину для изменения.
Чтобы избежать этого, многие обращаются к сценарию, который впервые был описан Энтони Маркано (
@AntonyMarcano) при участии Энди Палмера (@AndyPalmer), Яна Молака (@JanMolak) и других.Паттерн Screenplay
Page objects – это хороший способ начать делать ваши тесты поддерживаемыми, но если вы не будете вести себя осторожно, они все равно могут со временем выйти из-под контроля.
Паттерн Screenplay (некогда известный как паттерн Journey) представляет из себя применение принципов проектирования SOLID для автоматизированного приемочного тестирования и помогает командам решать эти проблемы. То есть, по сути, это то, что было результатом безжалостного рефакторинга Page Objects с использованием принципов проектирования SOLID.
Паттерн Screenplay берет page objects и разбивает их на действительно крошечные кусочки. Некоторые тестировщики говорят о том, что это сделало их тесты более ремонтопригодными и надежными.
Еще одним существенным преимуществом является то, что он делает тестовые сценарии более удобочитаемыми.
Впервые я услышал про паттерн Screenplay на Automation Guild Session в 2017 году от Джона Смарта (
@Wakeleo), создателя одного из моих любимых фреймворков автоматизации тестирования, Serenity.Screenplay использует идею актеров, задач и целей для формального описания тестов, отказываясь от терминов взаимодействия с системой. В Screenplay вы описываете тесты в терминах актера, у которого есть цели.
Вот пример:
Пример реализации паттерна Screenplay из Automation Guild Session 2017 от Джона Смарта
На первый взгляд может показаться, что использовать этот паттерн гораздо сложнее, чем тот же Page Objects, однако Джон упомянул, что использование этого подхода экономит командам, с которыми он работал, много времени за счет уменьшения затрат на обслуживание и поддержку.
Порты и адаптеры
Архитектура портов и адаптеров направлена на то, чтобы убедиться, что вы используете принцип единой ответственности, то есть конкретный объект должен делать что-то одно и иметь только одну причину для изменения.
Когда вы применяете его при автоматизации, убедитесь, что вы отделили код тест-кейса от всего остального, чтобы иметь возможность менять местами медленные компоненты и быстрые симуляторы, тем самым позволяя запускать тест и тестируемое приложение в одном процессе.
Избавьтесь от сетей и интерфейсов ввода/вывода, чтобы ничего не замедляло работу тестового набора. Конечно, сделать это нелегко, но чем больше вы будете к этому стремиться при создании автоматизации пользовательского интерфейса, тем лучше это будет для вас.
Я узнал об этом паттерне во время интервью с создателем Cucumber, Аслаком Хеллесоем (
@aslak_hellesoy). Он описал его как стратегию получения быстрой обратной связи от сквозного тестирования Cucumber.Аслак также порекомендовал ресурс, который называется Todo-subsecond, который я добавил в свой пост Top Resource for Test Automation Engineers. Это крошечное приложение с full-stack приемочными тестами, которые могут выполняться за миллисекунды. Его цель заключается в том, чтобы проиллюстрировать основные методы достижения этого в любой системе. Прорешав серию упражнений, вы познакомитесь с особым способом реализации test-driven и behavior-driven разработки.
Presenter First
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD).
Впервые я узнал об этом паттерне из интервью с Сэб Роуз
(@SebRose), одного из контрибьюторов в проект Cucumber и автора книги Cucumber for Java.Он говорил о том, что если вы нарисуете паттерн MVC в виде блоков и стрелок, то увидите, что представление, которое является вашим пользовательским интерфейсом, имеет четко определенные связи с моделью и контроллером. Если вы в рантайме можете заменить их моделями и контроллерами, которые создает и контролирует ваш тест, тогда не останется причин, по которым вы не сможете проверить, что пользовательский интерфейс ведет себя не так, как вы хотите.
Также вы можете настроить свою модель и контроллер так, чтобы они имитировали все виды странного поведения, например, выход сети из строя.
86 других паттернов автоматизированного тестирования
Я написал эту статью много месяцев назад, но так и не опубликовал ее.
Я был уверен в своем списке, до того момента, как я поговорил с Сереттой Гамба, автором новой книги A Journey through Test Automation Patterns, где она и ее соавтор Дороти Грэхем рассказывают о 86 паттернах!
Они разбивают паттерны на четыре отдельные категории: паттерны процессов, паттерны управления, паттерны проектирования и паттерны выполнения.
Те, что я описал, относятся к шаблонам проектирования, но существует множество других паттернов, которые решают проблемы, связанные не только с кодом.
Например, есть паттерны, которые касаются плохой корпоративной культуры и моделей управления, которые, по моему опыту, как правило, сводят на нет все усилия по автоматизации тестирования.
Чтобы ознакомиться с полным списком, загляните в wiki по вопросам паттернов проектирования или закажите себе книгу с Amazon.
Узнать подробнее о курсе.
