Тесты и policy-as-code

Что отвечать

Несколько уровней. (1) Статический анализ - валидация HCL, стиль, типовые ошибки: `terraform validate`, `fmt -check`, `tflint`. (2) Security/compliance - HCL соответствует политикам: `checkov`, `trivy`, `tfsec`. (3) Unit tests - `terraform test` с mock-провайдерами, проверяет логику HCL без реального apply. (4) Integration tests - terratest или `terraform test` с реальными провайдерами в sandbox-аккаунте, поднимает инфру, проверяет, сносит. Не всё нужно на каждом проекте; чем больше HCL влияет на прод - тем глубже пирамида.

Что хотят услышать

Senior должен: - дать пирамиду: много дешёвых статических проверок внизу, мало дорогих интеграционных вверху - сказать что для библиотечного модуля (shared в org) нужны unit и integration тесты; для root-конфига одного приложения - часто хватает static + security - различить «тестировать HCL» (логика выражений, count, for_each) и «тестировать инфру» (что AWS реально подняла то что ожидалось) - упомянуть что AWS-tests медленные (минуты на apply), нужно изолировать в отдельный CI job с расписанием, не на каждый PR

Подводные камни

• ✗ Делать интеграционные тесты на каждый PR без sandbox-аккаунта - через неделю получаешь биллинг и rate-limits
• ✗ Думать что `terraform validate` это «тест» - это синтаксический linter, не тест
• ✗ Покрыть статикой 100% и забить на интеграцию - пропустишь баги взаимодействия с провайдером

Follow-up

• ? Какие тесты нужны для shared-модуля, который катают 10 команд?
• ? Чем «тестировать HCL» отличается от «тестировать реальный AWS»?
• ? Где провести границу: что в CI на каждый PR, что в nightly?

Что отвечать

`terraform test` (с 1.6+) - HashiCorp'овский фреймворк, run-блоки пишутся на HCL, mock'ать провайдеры умеет из коробки, unit-тесты гоняются за секунды без apply. Terratest - Go-библиотека, реальные `terraform init/apply/destroy` под капотом, тестовые сценарии на Go: «подними, проверь через AWS SDK, снеси». Terratest - integration, терраформовский test - и unit (с mock), и integration (без mock). Сегодня в новом коде - в первую очередь встроенный test; terratest остаётся для сложных сценариев с проверкой через нестандартные API.

Что хотят услышать

Senior должен: - назвать ключевые отличия: HCL vs Go (DSL для тестов), mock из коробки vs только real-apply, скорость - сказать что mock-провайдеры в `terraform test` (с 1.7+) позволяют тестировать reference-logic, count, for_each, error handling - без денег и времени - упомянуть `run` блоки: каждый - изолированный сценарий, можно проверять plan-only (`command = plan`) или apply - назвать критерий выбора: для нового проекта в 2026 - `terraform test`; для legacy с terratest - оставляй

Подводные камни

• ✗ Думать что встроенный test заменяет terratest всегда - для проверок через нестандартные API (Kafka admin API, к примеру) Go всё ещё удобнее
• ✗ Запускать integration-tests без TTL на ресурсах - забытый тест-стенд может месяц жить в AWS
• ✗ Не уметь mock'ать в `terraform test` - в 1.7+ есть, читать документацию по mock_provider блоку

Follow-up

• ? Что делает `mock_provider` в `terraform test`?
• ? Чем `command = plan` отличается от `command = apply` в run-блоке?
• ? Когда terratest всё ещё лучше встроенного `test`?

Что отвечать

`tflint` - HCL-linter с провайдер-знанием: ловит deprecated arguments, неверный instance type, ссылки на несуществующие resource'ы. `checkov` - policy scanner: «бакет публичный», «RDS без шифрования», «IAM-роль слишком широкая». Запускается на HCL, plan, JSON-export. `trivy` - универсальный scanner для контейнеров, IaC, секретов в коде; для Terraform похоже на checkov, плюс репорты в SARIF для GitHub Security tab. Обычная связка: tflint в pre-commit, checkov или trivy на PR.

Что хотят услышать

Senior должен: - различить linter (структура, deprecation) и policy scanner (security, compliance) - сказать что одного scanner'а часто достаточно - checkov и trivy конкурируют по покрытию, ставить оба - дубль правил - упомянуть что любой scanner даёт false positives; жизнь начинается с baseline-suppress'ов на existing-кодовую базу - назвать что `tfsec` поглощён trivy с 2023 - в новом коде trivy

Подводные камни

• ✗ Включить три scanner'а сразу без baseline'а - PR падает на сотнях warning'ов о существующих ресурсах, инженеры выключают все
• ✗ Думать что checkov найдёт логические баги - нет, только pattern matching по правилам
• ✗ Использовать tflint без `--config` - default-правила могут не соответствовать твоей конвенции

Follow-up

• ? Чем trivy для IaC отличается от checkov по подходу к правилам?
• ? Как ввести scanner в legacy-проект без paralysis от warning'ов?
• ? Куда писать кастомные правила checkov?

Что отвечать

OPA (Open Policy Agent) - язык правил Rego и движок исполнения. `conftest` - CLI-обёртка OPA для проверки структурированных файлов (JSON, YAML, HCL plan-export). Используется когда checkov-правил мало или нужна корпоративная политика: «во всех S3 bucket'ах tag Owner непустой», «IAM-роли только с конкретным naming». Пишешь правила на Rego, гоняешь conftest на `terraform show -json plan.tfplan`. OPA глубже чем checkov: full programming language для условий, может ходить во внешние данные.

Что хотят услышать

Senior должен: - назвать что Rego декларативный, имеет свой синтаксис, learning curve - сказать что OPA нужен когда policy сложная или зависит от корпоративного контекста (lookup в HR-систему для approver'ов) - упомянуть `terraform show -json plan.tfplan | conftest test -` как канонический паттерн - назвать альтернативу: Sentinel в Terraform Cloud/Enterprise, своя политика-language от HashiCorp, проще Rego, но привязка к TFC

Подводные камни

• ✗ Начать с OPA когда хватило бы checkov - команда тратит недели на Rego вместо первой версии policy
• ✗ Запускать conftest на HCL вместо plan-output - HCL не показывает computed-значения, плюс не отражает финальные decisions провайдера
• ✗ Писать Rego без тестов - правила должны иметь свои unit-tests в самом OPA

Follow-up

• ? Чем Sentinel отличается от OPA?
• ? Что нужно подать на вход conftest: HCL или plan-JSON?
• ? Как протестировать Rego-правило?

Что отвечать

Снизу вверх: (1) static-analysis (validate, fmt, tflint) - секунды, ловит typos и стиль; (2) policy/security scanners (checkov, trivy) - десятки секунд, ловит небезопасные паттерны; (3) unit-tests (`terraform test` с mock) - секунды-минуты, проверяет логику HCL; (4) integration-tests (terratest или test с real provider) - минуты- часы, реальный apply в sandbox. Ломается обычно на интеграции: медленно, нестабильно, дорого. Команды либо забивают и держат только нижние уровни (рискуя), либо делают интеграцию nightly а не на каждый PR (разумно для большинства).

Что хотят услышать

Senior должен: - выстроить пирамиду по принципу «дёшево внизу, дорого вверху» - назвать что для shared-модулей integration-tests обязательны; для leaf-приложений - часто избыточны - сказать что non-determinism на интеграции (eventual consistency, rate limits) делает их flaky - нужен retry, backoff, тщательная очистка между запусками - упомянуть что test execution time напрямую влияет на iteration velocity команды; если CI зелёный через час - PR-цикл сломан

Подводные камни

• ✗ Считать что integration-tests нужны на каждый PR - не нужны, кроме критичной инфры
• ✗ Не очищать ресурсы после integration-tests - sandbox-аккаунт через месяц забивается осиротевшими EC2
• ✗ Не назначить владельца тестам - flaky-тесты никто не чинит, через полгода CI зелёный условно, баги просочились

Follow-up

• ? Где в пирамиде размещаются policy-scanners?
• ? Как держать integration-tests быстрыми?
• ? Что такое flaky-test и как его лечить в IaC?