Большинство статей по паттернам - весьма абстрактны, это верно. Для того, чтобы понять, как их применять именно в test automation, не достаточно лишь прочитать определения и парочку примеров.
Вся проблема в том, что будучи начинающим программистом / автоматизатором, у вас пока еще не сформировано абстрактное видение различных архитектурных нюансов. На данный момент, читая чей-то код, вы можете понимать, к примеру, лишь синтаксическую составляющую, но не иметь ни малейшего представления об архитектурной. Это сродни тому, как в универе мы могли зубрить различные мат. формулы, но абсолютно не понимать их практического жизненного применения.
Другая проблема - отсутствие опыта в дизайне собственных рабочих решений, которые бы успешно могли применяться на различных проектах с минимальным затратами на адаптацию.
Вы отталкиваетесь лишь от своего небольшого опыта, потому, увы, применимость многих вещей вам пока еще может быть совершенно не понятной. Паттерны - не исключение.
Касательно применимости в целом, по своему опыту могу заключить следующее (прим. - говорю с позиции Java automation engineer):
- Часть всеми известных паттернов уже стала совершенно неактуальной, ввиду грандиозных апдейтов 8й версии. Некоторые паттерны теперь имеют совершенно другой вид (в большинстве - упрощенный).
- Основная часть паттернов в чистом виде больше применима для продуктовой разработки. Для автомейшена нередко приходилось немного их модифицировать, в зависимости от контекста.
- Не следует пытаться рефакторить код, натыкивая паттернов везде, где не попадя. Подобные бездумные шаги могут привести к абсолютно ненужному усложнению кода и костыльным решениям.
Какие паттерны наиболее применимы в автоматизации? Однозначного ответа нет, ибо, как я уже заметил выше, многое зависит от контекста. Для web-automation из актуального я бы выделил следующие:
-
PageObject (не нуждается в представлении).
-
Factory берет на себя задачи инициализации сложных однотипных объектов, отдавая вам лишь результат (pages / drivers).
-
Facade может объединять различные компоненты одной большой системы, предоставляя пользователю более простую, интуитивно понятную единую точку доступа. В частном случае, может быть реализован в форме BasePage.
-
Decorator может, к примеру, сокрывать в себе логику неявной инициализации кастомных локаторов, расширяя уже существующий механизм, без прямого структурного вмешательства.
-
DAO предоставляет простой user-fiendly доступ к вашим entities, отделяя low-level DB API от высокоуровневых сервисов. В автомейшене от него было больше overhead, чем пользы. Потому пришлось изобретать некий generic DAO в связке с кастомным DataProvider. От точечных реализаций отказался со временем.
-
Singleton служит для предоставления единственного экземпляра объекта на протяжении всего ЖЦ исполняемого кода (или его изолированного участка). Может быть применим допустим к драйверу (если параллелизация по thread не предполагается), или к DB connection (чтобы каждый раз его не переоткрывать).
-
Builder применим для построения сложных объектов. В чистом виде мне не очень по душе. Для себя выработал некую модификацию. Применяю, когда есть entity с большим числом кастомных филдов, часть из которых могут быть опциональными (к примеру, Jira сущности).
Есть еще ряд других хорошо применимых паттернов, но уже для более сложных задач, к примеру, в проектировании собственного фреймворка или какой-либо библиотеки.
Понимание всех этих вещей приходит только с опытом. При наличии практики, со временем вы начнете смотреть на код более абстрактно, выделяя в нем не только синтаксические конструкции, а и те же паттерны; научитесь смотреть на компоненты, собирая из них пазл глобальной архитектуры.