Ответ.

История вопроса:

Изначально автоматические тесты часто писались "в лоб", без архитектурных разделений: логика проверки и механизмы исполнения перемешивались. С ростом проектов стало очевидно, что смешивание фреймворка и тест-логики создает хрупкую, трудно поддерживаемую кодовую базу. Появились архитектурные рекомендации по разделению ответственности.

Проблема:

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

Решение:

Строго разделять:

Фреймворк (baseline infrastructure): общая механика запуска тестов, логгирование, обработка ошибок, репорты, база для вспомогательных классов (например, драйвера, адаптеры и утилиты).
Тестовая логика (test cases): конкретные сценарии, которые выражают смысловую цель теста, используют только публичные API фреймворка.

Ключевые особенности:

Легкость поддержки благодаря изоляции платформенных изменений
Возможность переиспользовать тестовую логику
Уменьшение избыточности и дублирования кода

Вопросы с подвохом.

Можно ли писать тестовые шаги напрямую в тестах, если их очень немного?

Не стоит. Даже короткие тесты могут вырасти, и отсутствие слоев быстро приведет к хаосу.

Должны ли тестовые сценарии знать о механике запуска (например, когда инициализировать драйвер)?

Нет. Все детали инфраструктуры должны скрываться в слое фреймворка.

Нормально ли хардкодить параметры тестов внутри кейсов (например, url, креды)?

Нет. Параметры тестов должны конфигурироваться через настройки фреймворка и окружения.

Типовые ошибки и анти-паттерны

Размещение проверки состояния внутри методов фреймворка, а не тестов
Использование приватных методов фреймворка в тестах
Дублирование вспомогательных функций в тестах
Хардкод параметров

Пример из жизни

Негативный кейс

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

Плюсы:

Можно быстро начать писать автотесты без архитектуры

Минусы:

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

Позитивный кейс

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