Terraform Testing Framework Vocabulary для IT-професіоналів
Вивчайте англійську лексику для тестування Terraform: модульні тести, тести інтеграції, насмішки, твердження плану, Terratest і терміни якості інфраструктури як коду для інженерів DevOps.
Тестування інфраструктурного коду стало першокласною інженерною дисципліною. За допомогою власної платформи тестування Terraform (введеної у версії 1. 6) та інструментів, таких як Terratest, ви можете тепер писати тести модулів та тести інтеграції для вашої інфраструктури як коду. Щоб брати участь у перегляді коду, писати підручники з тестування або пояснювати вашу стратегію тестування англомовним колегам, вам потрібна правильна лексика. Цей посібник містить основні терміни з прикладами з реальних розмов з інженерами з інфраструктури.
Чому тестувати код інфраструктури?
Перед словником, зрозумій рамку. У технічних обговореннях англійською ви часто почуєте:
- “Коди інфраструктури слід розглядати як коди програм — вони потребують перевірки.”
-
- “Ми виявили неправильно налаштовану групу безпеки в тесті блоку, перш ніж вона торкнулася справжнього облікового запису AWS.” *
- “Наш конвеєр CI запускає
terraform testна кожному запиті на завантаження.”
Цей підхід — розгляд інфраструктури як програмного забезпечення — є контекстом для всіх словників нижче.
Основний тестовий словник (Core Testing Vocabulary)
Одиниця вимірювання
** Unit test ** перевіряє невеликий, ізольований шматок коду без зовнішніх залежностей. У контексті Terraform, тестування модулів перевіряє логіку модулів — типові змінні, умовні вирази, конвенції іменування — без створення реальних хмарних ресурсів.
«Тестування блоків перевіряє, що модуль присвоює правильні теги на основі змінної середовища — не потрібні виклики AWS»
Національний terraform test framework Terraform підтримує тестування блоків через мокінг.
Тестування інтеграції
** Перевірка інтеграції ** перевіряє, чи компоненти працюють разом правильно, зазвичай, включаючи справжні зовнішні системи. У тестуванні інфраструктури, тести інтеграції забезпечують реальні хмарні ресурси і перевіряють їх властивості.
«Тест інтеграції створює справжній VPC, розгортає модуль в ньому і перевіряє, чи групи безпеки правильно приєднані»
Інтеграційні тести є повільнішими і дорожчими, ніж тести на одиницю, але забезпечують набагато більшу впевненість.
Тестування на стійкість до шкідливих програм (E2E)
** End-to-end тест ** (скорочено E2E) перевіряє всю систему від початку до кінця - наприклад, забезпечення повного середовища і перевірка того, що програма, що працює в ньому, є доступною і поводиться правильно.
«Тест E2E перевертає повне середовище стажування і відсилає запит на перевірку стану до кінцевої точки балансування навантаження»
Тернопільський обласний краєзнавчий музей
terraform test (Національний формат)
** terraform test ** — це вбудована команда тестування, додана у Terraform 1. 6. Він запускає .tftest.hcl файли, які містять тестові сценарії з утвердженнями.
«Ми мігрували з bash-скриптів до
terraform test— рідна платформа інтегрується набагато краще з реєстром модулів»
Блок тестового запуску
**run блок ** в .tftest.hcl файлі визначає один сценарій тестування: що plan або apply, і які твердження перевірити. Кілька блоків виконання виконуються послідовно у тестовому файлі.
«Кожен блок запуску або планує, або застосовує конфігурацію — запуски тільки плану є швидшими і не викликають хмарних витрат»
Assertion
assertion це твердження, яке перевіряє чи умова є істинною. Якщо твердження зазнає невдачі, то і тест зазнає невдачі. У тестах Terraform, твердження використовують блок assert для перевірки атрибутів ресурсів.
«Утвердження перевіряє, чи ввімкнено версію S3 bucket — якщо ні, тест зазнає невдачі з описовим повідомленням про помилку.»
Фальшивий постачальник
** Мок провайдер ** замінює справжнього Terraform провайдера (наприклад, aws, google ) з імітованою версією, яка повертає фальшиві дані ресурсу без здійснення реальних викликів API. Це дозволяє швидке, безкоштовне тестування блоків.
«З мок провайдером, тестування блоків виконується в мілісекундах замість хвилин — не створюються реальні екземпляри EC2»
Мок ресурс / Мок джерело даних
** ілюзійний ресурс ** або ** ілюзійне джерело даних ** визначає фальшиві значення повернення для ресурсів або джерел даних у межах ілюзійного надання послуг. Ви можете вказати, що « повертає » надавач, щоб логіку вашого модуля можна було перевірити самостійно.
«Ми насміхаємося над джерелом даних
aws_caller_identity, щоб повернути ідентифікатор тестового облікового запису — це дозволяє нам перевірити формат ролі IAM ARN без реальних даних AWS»
Концепції інфраструктурного тестування
Terratest
** Terratest ** — це популярна платформа для тестування на основі Go від Gruntwork для тестування інфраструктури. За допомогою цього інструменту ви можете написати тести інтеграції на мові Go, які забезпечують реальні ресурси, виконують перевірки, а потім очищають їх.
«Ми використовуємо Terratest для тестування інтеграції — він забезпечує модуль, перевіряє, чи відповідають виходи очікуванням, і знищує все після тестування»
Підтвердження плану
plan assertion перевіряє вміст виводу terraform plan без фактичного застосування змін. За допомогою цього пункту можна перевірити, чи плановані зміни відповідають очікуваним, наприклад, чи буде створено лише одну групу безпеки.
«План твердження захопив випадкове відтворення бази даних — хтось змінив ідентифікатор підмережі, що змушує замінити.»
Idempotency
** Ідемпотентність ** означає, що застосування однієї операції декілька разів дає той самий результат. Хороший Terraform модуль є ідемпотентним: запуск terraform apply двічі поспіль не повинен робити ніяких змін на другому запуску.
«Наш тест запускає
applyдвічі і стверджує, що другий запуск показує нуль запланованих змін — це перевіряє ідемпотентність»
Drift
** Дрейф ** (або ** конфігурація дрейфу **) відбувається, коли реальна інфраструктура відхиляє від стану Terraform - наприклад, хтось вручну змінив ресурс в консолі AWS.
«Тест інтеграції виявив дрейф — правило групи безпеки було додано вручну, що не в нашій конфігурації Terraform»
Очищення / Teardown
** Очищення ** (або ** розбирання **) — це процес знищення ресурсів, створених під час тестування, після його завершення. Нездатність прибрати марнує гроші і забруднює середовище хмар.
Завжди використовуйте
deferв Terratest, щоб забезпечити теарdown запуски навіть якщо тест панікує — інакше ви закінчите з сиротами ресурсів
CI/CD-інтеграційний словник
Стадіон «Південний»
** Стадія конвеєра ** є кроком у конвеєрі CI/ CD. Стадії тестування зазвичай включають: validate, plan, unit test, integration test, перед стадією deploy.
“Стадія тестування блоків запускається на кожному затвердженні; стадія тестування інтеграції запускається тільки на запитах pull, що націлені на головну гілку.”
Тестове покриття
** Покриття тестування ** вимірює, наскільки багато вашого коду використовується під час тестування. Для коду інфраструктури, значення « покриття » може означати: скільки модулів має тести, або який відсоток комбінацій змінних буде перевірено.
«Ми маємо 80% покриття тестування модулів — решта 20% — це застарілі модулі, які ми не мали часу модернізувати»
Профілактичні дослідження
** фрагментарний тест ** — це тест, який іноді проходить, а іноді не проходить без будь- яких змін коду, зазвичай через проблеми з часом, нестабільність зовнішньої служби або забруднення тестового середовища.
«Тест інтеграції є нерівним — він іноді зазнає невдачі, тому що роль IAM не поширюється глобально до наступного запуску твердження»
Ключові слова
- ** run a test suite ** — « Ми запускаємо повний набір тестів при кожному об’ єднанні з головним. »
- write assertions — « Записувати утвердження для кожної змінної виводу, яку використовує ваш модуль. »
- ** mock a provider ** — « Створити ілюзію провайдера, щоб прискорити тестування модулів »
- detect drift — « Використовуйте
terraform planу CI для автоматичного виявлення дрейфу » - ** test coverage ** — « Збільшити тестовий охоплення перед переробкою мережевого модуля. »
- ** clean up resources ** — « Завжди очищати ресурси після тестів інтеграції — від цього залежить керування витратами »
- integration test environment — « У нас є спеціальний обліковий запис AWS для тестового середовища інтеграції. »
- ** pass / fail a test ** — « Спроба виконання затвердження зазнала невдачі, оскільки назва контейнера не відповідає правилам іменування. »
Фрази для перегляду коду і стоянок
-
- “Цей модуль ще не має жодних тестів — чи можете ви додати хоча б твердження плану для головного шляху успіху?” *
-
- “Тести інтеграції тривають 20 хвилин. Чи можемо ми витягнути логіку, що піддається тестуванню, і насміхатися над провайдером для цих випадків?»*
-
- “Конвейєр червоний, оскільки перевірка на ідемпотентність зазнала невдачі — друге застосування створює нову групу безпеки замість розпізнавання існуючої.” *
-
- “Ми повинні додати повторну спробу тесту з невеликою кількістю помилок до налаштувань CI — затримка розповсюдження IAM спричиняє періодичні помилки.” *
- “Мок провайдер дозволяє нам тестувати логіку іменування без торкання реального облікового запису AWS — це правильний підхід для тестів одиниць.”
Practice
Виберіть модуль Terraform, з яким ви працюєте, і напишіть короткий план тестування англійською мовою — від 4 до 6 речень — з описом того, що ви хочете перевірити і як. Вкажіть, які сценарії використовуватимуть тести модулів з імітацією постачальників, а які потребуватимуть повної інтеграції тестів з реальними ресурсами. Використовуйте принаймні 6 термінів з цього підручника: * тест одиниць *, * тест інтеграції *, * імітаційний провайдер *, * твердження *, * ідемобільність *, * очищення *, * твердження плану *, * тест на тріщини *, * дрейф *. Записання цього допоможе вам виявити прогалини у вашій стратегії тестування, а також вправлятися у технічній англійській.