Screenplay Pattern строит автотест вокруг участника и его цели. Вместо набора страниц сценарий описывает, что делает покупатель, менеджер или администратор, какими возможностями пользуется и какие ответы получает. Это помогает говорить на языке предметной области, когда цепочки пересекают несколько экранов или протоколов.
Паттерн особенно заметен в крупных acceptance-наборах. Оформление заказа может использовать браузер, подготовка пользователя — API, проверка события — отдельный клиент. Screenplay позволяет разделить эти механизмы, сохранив на верхнем уровне понятную цель. Цена такого разделения — дополнительные понятия и требования к дисциплине команды.
Основные участники модели
Actor — участник сценария, например покупатель Анна. Ability — доступная ему техническая возможность: работать с браузером или вызывать API. Task — цель уровня бизнеса, например оформить заказ. Interaction — конкретное действие, например нажать кнопку. Question — получение наблюдаемого ответа, например итоговой суммы.
Названия и API различаются между реализациями. Эти понятия не требуют конкретной библиотеки, но готовый фреймворк может обеспечить композицию, отчётность и интеграцию с runner. Перед внедрением выбирают язык и реализацию, а затем используют её документацию, вместо смешивания примеров из разных экосистем.
Как меняется структура сценария
В Page Object сценарий часто обращается к корзине, оплате и странице подтверждения. В Screenplay он поручает актору «оформить заказ с доставкой» и спрашивает «каков статус заказа». Объекты элементов могут остаться внутри низкоуровневых взаимодействий: подходы не обязательно исключают друг друга.
Полезная граница проходит между намерением и механизмом. Изменение кнопки затрагивает interaction, изменение бизнес-процесса — task, изменение способа аутентификации — ability или подготовку. Если любое изменение заставляет переписывать все слои, разделение осталось формальным.
Практический пример: согласование возврата
В учебном магазине покупатель создаёт заявку на возврат, а менеджер её подтверждает. Покупателю доступен только собственный заказ. Менеджер работает с очередью заявок. Возьмите отдельный заказ в допустимом состоянии и двух тестовых пользователей; реального возврата денег в упражнении нет.
Сценарий описывает две цели: Анна подаёт заявку, Борис согласует её. После первого действия ожидается статус requested и видимость в очереди менеджера. После второго — approved у заявки и подтверждение для покупателя. Проверка запрещённого подтверждения покупателем является отдельным негативным примером.
Как разложить задачи
Задача «подать заявку» получает идентификатор заказа и причину, но не должна сама выбирать случайный заказ из списка. Внутри она открывает нужную запись, заполняет причину и отправляет. Задача «согласовать» получает идентификатор созданной заявки, поэтому связь между действиями участников остаётся явной.
Вопрос «статус заявки» читает состояние тем способом, который соответствует цели теста. Если проверяют экран, ответ берут из UI. Если проверяют процесс между сервисами, допустимо наблюдать API. Замена UI-чтения API-чтением не должна незаметно исключать проверку пользовательского отображения.
Несколько акторов и изоляция
У каждого актора должна быть собственная сессия и контролируемая роль. Два имени в отчёте не обеспечивают изоляцию, если оба используют один browser context с общей cookie. Для браузерного сценария создают отдельные контексты; для API — отдельные клиентские credentials.
Данные также связывают с конкретным прогоном. Задача менеджера не должна брать «первую заявку», поскольку параллельный тест может создать другую. Передача ID и явная проверка владельца делают многопользовательский сценарий воспроизводимым и помогают обнаруживать ошибки доступа.
Что делать с assertions
Question предоставляет факт, а expectation сравнивает его с требованием. Например, «статус заявки» должен быть approved. Действие «согласовать» не должно всегда автоматически утверждать весь результат: оно может использоваться в сценарии запрещённого перехода или недоступной зависимости.
Сообщение об отказе должно сохранять контекст актора и бизнес-цели. Ошибка «ожидали approved, получили requested для заявки return-42» гораздо полезнее, чем исключение внутри универсального click. Хорошая отчётность является следствием ясных задач, а не заменой этой ясности.
Где Screenplay помогает
Подход полезен, когда одни цели повторяются в разных цепочках, есть несколько ролей и набор требует читаемой бизнес-истории. Например, добавление товара и изменение количества могут участвовать в оплате, резервировании и возврате. Общая задача сокращает повторение без привязки верхнего сценария к конкретному экрану.
Но повторное использование должно сохранять смысл. Универсальная задача «выполнить шаг с параметрами» фактически становится интерпретатором и теряет предметный язык. Параметры должны описывать данные цели, а не скрытые команды браузера.
Когда стоимость не оправдана
Для нескольких простых экранов небольшой Page Object часто понятнее. Screenplay добавляет интерфейсы, классы и правила композиции, которые команда должна освоить. Если участники не могут самостоятельно разобрать отказ, архитектура повышает зависимость от одного автора.
Проведите пилот на одной реальной цепочке. Сравните изменение локатора, добавление негативного случая и чтение отчёта новым сотрудником. Критерий успеха — уменьшение повторения и более понятная диагностика, а не число созданных Task-классов.
Типичные проблемы внедрения
Частая ошибка — задача на каждый клик. Тогда бизнес-сценарий превращается в длинный технический список. Обратная ошибка — одна гигантская задача на весь процесс, внутри которой спрятаны данные, роли и проверки. Обе крайности уничтожают управляемость границ.
Не помещайте mutable-состояние всех акторов в общий singleton. Не передавайте секреты через описания задач, попадающие в отчёт. Не рассчитывайте, что переименование page methods в tasks само по себе изменит качество набора: требуется пересмотреть ответственность компонентов.
Что должен вынести QA
Screenplay помогает выразить роли, возможности, цели и наблюдения отдельно. Он особенно полезен для составных сценариев и нескольких участников, если команда готова поддерживать понятный предметный язык.
Начинать стоит с конкретной боли: повторяющихся бизнес-действий, запутанных ролей или плохой читаемости. Затем проверять, решает ли модель эту проблему на практике. Зрелость архитектуры определяется ясностью изменений и отказов, а не сложностью используемого паттерна.