Какие паттерны проектирования автотестов существуют и примеры?

Что проверяют

Умеете ли вы строить тестовый фреймворк, который переживёт редизайн и сотню новых тестов, или знаете только термин Page Object. Следом спрашивают, где держать проверки, как хранить драйвер при параллельном запуске и откуда брать тестовые данные.

Как отвечать

Называйте паттерн и пример из своего стека (Selenium или Selenide на Java, Playwright, pytest):

• Page Object: класс на страницу с локаторами и действиями (login(user)), тест работает с действиями, а не с селекторами. В Playwright локаторы ленивые, PageFactory и @FindBy там не нужны;
• Page Component: шапка, таблица, модальное окно выносятся в свои классы и вкладываются в страницы;
• Fluent Interface: методы возвращают следующую страницу, сценарий читается цепочкой;
• Test Data Builder и Object Mother: объект с разумными значениями по умолчанию, в тесте меняется только важное: aUser().withRole(ADMIN).build();
• Data-driven: один сценарий на наборе данных через @ParameterizedTest в JUnit 5 или @pytest.mark.parametrize;
• Fixture: подготовка и очистка окружения, фикстуры pytest, @BeforeEach и расширения JUnit;
• Factory для драйвера: браузер и настройки берутся из конфигурации, а не зашиты в тест;
• Screenplay: акторы и задачи вместо страниц, для больших наборов тестов;
• AAA или Given-When-Then: структура самого теста.

Chain of Responsibility или Strategy называйте только с реальной задачей, например выбор способа авторизации в тестах. Без неё это звучит как пересказ учебника.

Где спотыкаются

Кладут проверки внутрь Page Object. Страница действует и отдаёт состояние, а решать, что верно, должен тест, иначе один класс обслуживает противоречивые сценарии.

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

Строят BasePage на тысячу строк и наследуют от него все страницы. Общее лучше выносить в компоненты.