|
|
@@ -0,0 +1,19 @@
|
|
|
+# Лекция 3: Принципы тестопригодного дизайна: от Dependency Injection до hexagonal architecture
|
|
|
+
|
|
|
+**Тестопригодный дизайн (Testable Design) — это архитектурный подход**, при котором система проектируется таким образом, чтобы ее компоненты могли быть легко, быстро и изолированно протестированы. Высокая связанность (tight coupling) и скрытые зависимости — главные враги тестируемости. Ключевым приемом для борьбы с ними является **Инверсия зависимостей (Dependency Inversion Principle, DIP)**, реализуемая через механизм **Внедрения зависимостей (Dependency Injection, DI)**, который передает зависимости компоненту извне, а не позволяет ему создавать их самостоятельно.
|
|
|
+
|
|
|
+
|
|
|
+*Ключевые слова для поиска изображения: dependency injection test double mock stub, hexagonal architecture ports and adapters*
|
|
|
+
|
|
|
+С технической точки зрения, DI **позволяет заменять реальные реализации зависимостей на тестовые дублеры (test doubles)** — моки (mocks), стабы (stubs), фейки (fakes). Это делает модульные тесты быстрыми (не требуют базы данных или внешнего API) и стабильными (не зависят от внешних сбоев). Архитектурные паттерны, такие как **Гексагональная архитектура (Hexagonal) или Чистая архитектура**, формализуют этот подход, разделяя систему на «ядро» (бизнес-логика) и «адаптеры» (работа с БД, UI, внешними сервисами). Зависимости направляются *извне внутрь* к ядру, которое ничего не знает о деталях реализации адаптеров.
|
|
|
+
|
|
|
+### Таблица 3. Уровни тестирования и соответствующие приемы тестопригодного дизайна
|
|
|
+| Уровень тестирования | Цель | Ключевые приемы дизайна | Инструменты для изоляции |
|
|
|
+|----------------------|------|--------------------------|--------------------------|
|
|
|
+| Модульное (Unit) | Проверить логику отдельного класса/функции в изоляции. | Внедрение зависимостей через интерфейс, принцип единственной ответственности. | Mock-библиотеки (Jest, Mockito, unittest.mock). |
|
|
|
+| Интеграционное | Проверить взаимодействие нескольких компонентов (например, сервиса и репозитория). | Использование in-memory баз данных (SQLite, H2), заглушек для внешних HTTP-сервисов (WireMock). | Тестовые контейнеры (Testcontainers), фикстуры данных. |
|
|
|
+| Контрактное (Contract) | Проверить совместимость интерфейсов между потребителем и поставщиком (микросервисы). | Явное определение и версионирование API-контрактов (OpenAPI/Swagger, gRPC proto). | Pact, Spring Cloud Contract. |
|
|
|
+
|
|
|
+Эффективный тестопригодный дизайн **требует дисциплины на этапе проектирования**. Код, который сложно протестировать, как правило, имеет архитектурные проблемы (нарушение SRP, высокое зацепление). Поэтому написание тестов — не только способ проверки корректности, но и **мощный инструмент обратной связи о качестве архитектуры**. Если для теста требуется неадекватно сложная настройка — это сигнал к рефакторингу.
|
|
|
+
|
|
|
+Таким образом, тестопригодный дизайн — это **не дополнительная нагрузка, а естественное следствие применения SOLID-принципов и модульной архитектуры**. Инвестиции в него на ранних этапах окупаются значительным снижением стоимости изменений и повышением надежности системы на протяжении всего ее жизненного цикла.
|
