Code Coverage & Testing Vocabulary: 25 Terms for QA and Developers (англійською)
Метрики покриття коду, типи тестів, мокінг, TDD, BDD і словник забезпечення якості для розробників і інженерів QA.
Тестування - це мова, яка відокремлює професійних розробників від любителів. Незалежно від того, чи ви інженер з контролю якості, який переглядає запит на витягування, чи розробник сервера, який захищає ваші показники поширення у виступі, знання правильного словника робить різницю між тим, щоб вас зрозуміли, і тим, щоб вас відкинули. Ця стаття охоплює 25 основних термінів, які щоденно використовуються в командах з контролю якості і інженерії — з реальними прикладами розмов, щоб ви могли почати використовувати їх відразу.
Основні терміни: Coverage Metrics
** Покриття коду ** — вимірювання, яке дає вам змогу дізнатися, який відсоток вашого коду виконується під час запуску вашого тестового набору. Зазвичай, його поділяють на чотири підтипи:
- ** Покриття рядків ** — відсоток окремих рядків, виконаних під час тестів.
- ** Покриття гілок ** — перевіряє, чи було перевірено кожну можливу гілку (наприклад, обидві сторони речення
if). - ** Покриття шляху ** — найбільш докладна метрика; забезпечує, що всі можливі шляхи через функцію було використано.
- ** Покриття функцій ** — підтверджує, що кожна функція або метод у базі коду було викликано принаймні один раз.
«Ми злили його, але CI блокує PR — покриття гілок впало з 84% до 71% після вашого рефакторингу»
“Покриття лінії виглядає добре на 90%, але наше покриття відділень жахливе. Ми не тестуємо шляхи помилок взагалі»
** Набір тестів ** — повна збірка тестів для проекту або компонента, які часто впорядковано у теки за типом або можливостями.
“Все тестування займає 12 хвилин, щоб запустити локально. Саме тому ми запускаємо тільки тести блоків на перед-комміті»
«Давайте додамо ці нові краї до набору, перш ніж ми відправимо функцію»
** CI gate ** — обов’ язкова перевірка у конвеєрі постійної інтеграції, яка блокує об’ єднання, якщо перевірки зазнають невдачі або рівень покриття опускається нижче визначеного порогу. Також називається * обов’ язковою перевіркою стану *.
Ваш PR не може бути злито — CI-ворота не спрацьовують на трьох тестах одиниць
«Ми додали CI-ворота в останньому спринті, щоб ніхто не міг випадково відправити з менш ніж 80% покриттям»
Проте, всі інші типи тестів повинні бути відомі
** Unit test ** — тест, який перевіряє одну функцію, метод або клас у повній ізоляції від решти системи. Швидкий, зосереджений, і фундамент тестової піраміди.
«Напишіть тест-уніту для цієї функції перевірки спочатку — вона має чотири гілки і ніяких тестів взагалі»
** Перевірка інтеграції ** — перевірка, яка перевіряє, як дві або більше компонент працюють разом. Повільніше, ніж тести модулів, але виявляє невідповідності інтерфейсу, які пропускають тести модулів.
“Всі тести на модулі пройшли, але тест інтеграції платіжної служби провалився. Формат тіла запиту змінено.”
** End- to- end test (E2E) ** — тест, який імітує справжню подорож користувача по всій програмі, від інтерфейсу до бази даних. Найдорожчий тип тестів, що потребує написання і підтримки.
Процитовано 2011-02-10. The E2E suite is flaky again — Cypress times out on the checkout page whenever the staging environment is slow
** Смоук тест ** — поверхневий, швидкий тестовий запуск, який перевіряє, чи запускається програма і чи працює основна функціональність. Використовується для вирішення питання про те, чи варто продовжувати з більш глибоким тестуванням.
“Спочатку проведи димові тести. Якщо поток входу пошкоджений, то немає сенсу запускати повний набір регресії»
** Регресійний тест ** — тест, який перевіряє, чи працює поведінка, яка раніше працювала, після зміни коду. Комплекти регресії зростають з часом і захищають від повторного введення старих помилок.
«Ми потребуємо регресійного тесту для цієї помилки, перш ніж ми закриємо квиток, інакше вона повернеться через три місяці»
** Перевірка на мутації ** — це досконала техніка, за допомогою якої інструмент автоматично вводить невеличкі вади (* мутації *) у ваш код, щоб перевірити, чи не виявили їх ваші тести. Если мутант выживает, значит, ваши тесты недостаточно сильны.
«Наше покриття становить 90 %, але тестування на мутації показало, що половина тестів насправді не стверджують нічого значущого»
** Тестування на основі властивостей ** — замість написання певних прикладних вхідних даних, ви визначаєте * властивості *, які завжди повинні бути вказані, і програма генерує сотні випадкових вхідних даних, щоб спробувати їх розібрати. Популярні інструменти включають Hypothesis (Python) і fast-check (JavaScript).
«Я перейшов на тестування на основі властивостей для серіалізатора — він знайшов кращий випадок з символами Unicode, які я ніколи б не думав тестувати вручну»
Тестові подвійки: стрижні, клоуни, шпигунки, фальшивки і манекени
Термін ** test double ** є загальною назвою для будь- якого об’ єкта, який замінює реальну залежність у тесті. Існує п’ять підтипів, і змішування їх є поширеним джерелом плутанини в перегляді коду.
- Stub — повертає закодовані відповіді на виклики. Використовується, коли вам потрібна залежність, яка повертає певне значення, щоб ви могли перевірити поведінку, що залежить від цього значення.
- ** Мок ** — заголовок, який також * перевіряє *, що його було викликано у очікуваний спосіб. Якщо мок не було викликано або було викликано з неправильними аргументами, тест зазнає невдачі.
- ** Spy ** — обгортає реальний об’ єкт і записує виклики до нього, надаючи вам змогу вказати, яким чином об’ єкт використовувався, без повного заміни об’ єкта.
- ** False ** — працююча, але спрощена реалізація (наприклад, база даних у пам’ яті замість справжньої).
- ** Dummy ** — об’ єкт, який було передано для задовольнення параметра підпису, але ніколи не використовувався у тесті.
«Ви використовували тут заголовок, але вам насправді потрібен імітаційний — ви хочете перевірити, що служба електронної пошти була викликана точно один раз»
«Замінити справжню базу даних на фальшиву для цих інтеграційних тестів, щоб нам не потрібно було живого з’єднання в CI»
«Це UserRepository в конструкторі є просто манекеном — функція під тестуванням ніколи не торкається його»
Концепція та концепції проектування
** Arrange- Act- Assert (AAA) ** — широко використовується шаблон для структурування окремих тестів. * Arrange *: налаштування даних і залежностей. * Act *: виклик коду під час тестування. * Assert *: перевірка результату. Збереження цих трьох фаз явними робить тести легшими для читання і зневадження.
“Ваш тест важко слідкувати, тому що фази аранжування і твердження змішані разом. Розділіть його на AAA»
Піраміда тестування — модель, яка рекомендує мати багато тестів на одиниці у основі, менше тестів інтеграції в середині і невелику кількість тестів E2E на вершині. Перевернута піраміда (багато E2E, кілька тестів на одиницю) призводить до повільних, крихких тестових наборів.
«Ми майже не маємо жодних тестів, але сотні тестів E2E. Піраміда повністю перевернута — саме тому цей аудіо-виступ триває 40 хвилин»
** Ізоляція тестів ** — принцип, що кожен тест повинен бути незалежним. Тест не повинен покладатися на стан, залишений попереднім тестом, і повинен очищати його після себе. Відсутність ізоляції є головною причиною невдач, залежних від порядку.
«Ці тести не спрацьовують, тільки якщо вони виконуються в алфавітному порядку — класична проблема ізоляції. Кожен тест повинен скинути базу даних»
** Флакі тест ** — тест, який дає непослідовні результати (іноді успішно, іноді не успішно) без будь- яких змін у коді. Неякісні тести підривають довіру до тестового набору і дорого коштують для дослідження.
“Це тестування було неоднозначним протягом двох тижнів. Давайте поставимо його на карантин і піднімемо окремий квиток, щоб виправити його належним чином»
** TDD (Test- Driven Development) ** — процес розробки, у якому ви пишете тест, який зазнає невдачі * перед* написанням реалізації, потім пишете мінімальний код, який дозволить йому пройти, а потім переробляєте його. Часто підсумовується як * червоний-зелений-рефактор *.
«Якби ми зробили TDD тут, ми б вловили цю прогалину вимог до написання однієї лінії реалізації»
** BDD (Behaviour-Driven Development) ** — розширення TDD, яке використовує мову, зрозумілу для бізнесу (часто * Given / When / Then * синтаксис), щоб описати очікувану поведінку системи. Заохочує співпрацю між розробниками, QA і менеджерами продукту.
«Команда продукту може фактично прочитати специфікації BDD і сказати нам, чи відповідають сценарії критеріям прийняття»
Як використовувати їх у розмові
У щоденних виступах і перегляді коду точний словник сигналізує досвід. Ось деякі з природних візерунків:
** Обговорення поширення: ** “Наше поширення рядків виглядає здоровим, але я хочу, щоб ми отримали поширення гілок до наступного випуску — є декілька шляхів помилок, які повністю не перевірені.”
** Перегляд запиту на завантаження: ** « Чи можете ви додати регресійний тест для виправлення? Також, це виглядає так, ніби це має бути мока, а не заголовок — нам потрібно запевнити, що служба сповіщення насправді викликається»
** Підвищення якості: ** “Піраміда тестування перевернута в цій службі. У нас 200 тестів E2E і 15 тестів на окремі елементи. Кожна збірка займає 25 хвилин, а рівень тестування тріщин становить близько 20%. Я б рекомендував рефакторний спринт, зосереджений на покритті одиниць»
** Пояснення помилки CI: ** « Шлюз CI блокує ваше злиття, оскільки тестування мутацій виявило, що три з ваших тверджень ніколи не досягаються. Тести пройшли, але вони також пройдуть, якщо функція поверне неправильне значення.”
Таблиця швидких посилань
| Term | One-Line Definition |
|---|---|
| Code coverage | Percentage of code executed by your test suite |
| Branch coverage | Whether every if/else branch has been tested |
| Unit test | Tests a single function or class in isolation |
| Integration test | Tests how two or more components work together |
| E2E test | Simulates a full user journey through the app |
| Flaky test | A test that passes and fails inconsistently |
| Test double | Any object substituting a real dependency in a test |
| Mock | A test double that also verifies how it was called |
| Arrange-Act-Assert | Standard three-phase structure for writing tests |
| CI gate | Pipeline check that blocks merges on test failure |
Завдяки цьому словнику ви зможете більш впевнено робити внесок у перегляд коду, сеанси оцінки і технічні інтерв’ ю. Виберіть три терміни, яких ви ніколи раніше не використовували уголос, і пошукайте наступну можливість використовувати їх у коментарі до запитів на витягнення або у коментарі до запитів на витягнення.