Что такое принципы SOLID?

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

1. S — Single Responsibility (Принцип единственной ответственности).

   • Суть: Класс или модуль должен иметь одну и только одну причину для изменения (одну ответственность).
   • Применение в автотестах: Разделяйте классы для работы с страницами (Page Object), классы для тестовых данных, классы для утилитарных функций (например, генерации данных) и классы для работы с API. Не стоит смешивать логику проверок (assertions) и логику взаимодействия с браузером в одном методе.

2. O — Open/Closed (Принцип открытости/закрытости).

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

3. L — Liskov Substitution (Принцип подстановки Барбары Лисков).

   • Суть: Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности программы.
   • Применение в автотестах: Если у вас есть базовый класс WebPage с методом isLoaded(), то любой класс, его наследующий (например, LoginPage, HomePage), должен корректно работать везде, где ожидается WebPage, не ломая логику проверки загрузки страницы.

4. I — Interface Segregation (Принцип разделения интерфейсов).

   • Суть: Много специализированных интерфейсов лучше, чем один универсальный.
   • Применение в автотестах: Вместо одного громоздкого интерфейса TestActions, который включает методы для UI, API и работы с БД, лучше создать отдельные интерфейсы: UiActions, ApiClient, DbHelper. Тогда класс, который работает только с API, не будет вынужден реализовывать ненужные ему UI-методы.

5. D — Dependency Inversion (Принцип инверсии зависимостей).

   • Суть: Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
   • Применение в автотестах: Класс теста не должен напрямую создавать экземпляр конкретного драйвера (ChromeDriver). Вместо этого он должен зависеть от абстракции WebDriver. Конкретная реализация драйвера (Chrome, Firefox) «инжектируется» (например, через конструктор) извне, что упрощает поддержку и тестирование.

Практическая польза для QA: Следование SOLID в коде автотестов снижает сцепление (coupling) и повышает связность (cohesion), что ведёт к уменьшению количества багов в самих тестах, упрощению их рефакторинга и увеличению скорости написания новых тестовых сценариев.