Design patterns: A better software testing technique

Большая часть успеха проектов по автоматизации заключается в переиспользовании известных паттернов тестирования, которые, как уже доказано, помогают повысить надежность сценариев автоматизации.

Паттерн проектирования автоматизированного тестирования – это то простое решение, которое день ото дня доказывает миру свою эффективность. Эти шаблоны также считаются лучшими практиками для любого проекта, построенного за счет объектно-ориентированного программирования.

Что такое Design Patterns, и для чего ни нужны?  

Паттерн проектирования — это часто встречающееся решение определённой проблемы при проектировании архитектуры программ. Дизайн паттерны это не конкретно решение, которое мы можем применить в нашем коде. Мы не можем просто взять и скопировать паттерн в программу. в отличие от готовых функций или библиотек. Можно сказать, что паттерн- это описание или общая концепция, который можно использовать в различных ситуациях как решение конкретных проблем.

Дизайн паттерны позволяют нам внедрять проверенные решения для известных проблем, таким образом экономя время и усилия при написании кода. Так же паттерны помогают при коммуникации в командах при обсуждении решения конкретных проблем. Например, вы можете сказать: "В нашем случае лучше использовать паттерн фабрика", и все вокруг поймут, что им нужно делать.

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

Из чего состоят паттерны?

В книге ‘Design Patterns’, говорится, что паттерн состоих из четырех основных элементов:

• Имя- используется для описания проблемы, решения и последствий;
• Проблема - описывает, когда необходимо применять данный паттерн, обьясняет проблему и контекст;
• Решение - мотивации к решению проблемы способом, который предлагает паттерн;
• Последствия - результат применения паттерна.

Такой формализм в описании позволил создать обширный каталог паттернов, проверив каждый из них на состоятельность.

Категории

Паттерны проектирования сгруппированы в три категории:

Структурные паттерны объясняют, как собирать объекты и классы в более крупные структуры, сохраняя при этом гибкость и эффективность этих структур.

Порождающие паттерны предоставляют различные механизмы создания объектов, которые повышают гибкость и повторное использование существующего кода.

Поведенческие паттерны связаны с алгоритмами и распределением ответственности между объектами.

Далее в статье будут рассмотрены самые популярные структурные, порождающие и поведенческие паттерны проектирования, в общих чертах будет описано, что они собой представляют, почему они полезны и как их структурировать.

SOLID

Прежде чем углубляться в шаблоны проектирования, важно ознакомиться с принципами SOLID, которые так же помогают сделать разработку программного обеспечения более понятной, гибкой и удобной в обслуживании.

SOLID принципы советуют, как проектировать модули, т.е. кирпичики, из которых строится приложение. Цель принципов — проектировать модули, которые:

• способствуют изменениям
• легко понимаемы
• повторно используемы.

The Single Responsibility Principle 

"A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class."

У класса должна быть только одна причина для изменения. 

The Open Closed Principle 

"Software entities ... should be open for extension, but closed for modification."

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

The Liskov Substitution Principle 

"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program."

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

The Interface Segregation Principle 

"Many client-specific interfaces are better than one general-purpose interface."

Cоздавайте мелкозернистые интерфейсы, ориентированные на клиента.

The Dependency Inversion Principle 

One should "depend upon abstractions, [not] concretions."

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Структурные паттерны

Page Object Models (POM) 

 Page Object – это шаблон проектирования, который широко используется в автоматизированном тестировании и позволяет разделять логику выполнения тестов от их реализации. Page Object как бы моделирует страницы тестируемого приложения в качестве объектов в коде. В результате его использования у вас получатся отдельные классы, отвечающие за работу с HTML каждой конкретной веб-страницы.

Данный паттерн полезен по следующим причинам:

• Такой подход значительно уменьшает объем повторяющегося кода, потому что одни и те же объекты страниц можно использовать в различных тестах. Необходимо только написать компоненты страницы (например, поля ввода, кнопки и т. Д.), которые используются при создании других объектов страницы.
• Данный паттерн обеспечивает инкапсуляцию и абстракцию. Объекты страницы инкапсулируют веб-элементы или другие члены класса и предоставляют доступ к методам оболочки, которые скрывают всю логику (то есть механизмы, используемые для поиска или изменения данных).
• Создание и организация объектов страницы упрощает разработчикам понимание структуры решения автоматизации посредством использования, создания новых тестов, создания новых компонентов страницы и удобочитаемости тестов.

Как он устроен?

Объекты страницы похожи на интерфейсы для веб-страниц или компонентов веб-страниц. Эти компоненты поддерживают такое же взаимодействие с другими веб-страницами и должны состоять из:

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

другие объекты страницы

методы для работы с объектом страницы и возврата других объектов страницы по дизайну

не следует использовать утверждения на объектах страницы