Мій CI/CD пайплайн проходив успішно протягом 3 місяців — а потім я прочитав логи
Зелені галочки приносять задоволення. Кожен pull request пройшов успішно. Кожен деплой спрацював.
Потім користувач повідомив про зламану функцію. Вона не працювала вже кілька тижнів.
Я відкрив логи пайплайну. Наші успішні білди нам брехали.
Наш процес виглядав ідеальним:
- Лінтинг
- Юніт-тести
- Інтеграційні тести
- Білд
- Деплой
Протягом місяців кожен етап мав 100% успішності.
Кнопка експорту нічого не робила при натисканні. Помилок не з'являлося. Я відстежив проблему до змін 11-тижневої давнини. Пайплайн пройшов. Code review було схвалено. Функція була зламана від самого початку.
Проблема була не в нашому коді. Вона була в нашому тестовому коді.
Наші інтеграційні тести використовували моки для всього. Ми замокали весь сервіс експорту. Тест перевіряв мок замість реального коду. Мок завжди повертав статус успіху.
Ми потрапили в пастку надмірного використання моків:
- Юніт-тести: Замокали все, щоб ізолювати юніт. Це нормально.
- Інтеграційні тести: Замокали все заради швидкості. Це помилка.
- E2E-тести: Пропустили цей конкретний сценарій.
Наші інтеграційні тести були просто дорогими юніт-тестами. Вони перевіряли, що наші моки працюють. Вони не перевіряли, що працює наш код.
Щоб це виправити, я вніс три зміни:
Обмежити використання моків лише юніт-тестами. Інтеграційні тести мають взаємодіяти з реальними базами даних, API та файловими системами. Якщо тест повільний, не приховуйте це моком. Використовуйте цю швидкість як сигнал до оптимізації.
Додати контрактні тести. Вони гарантують, що ваші моки відповідають реальній поведінці сервісу. Якщо мок повертає дані, які реальний сервіс не повернув би, контрактний тест провалиться.
Відстежувати реальне покриття. Ми перестали дивитися на просту відсоткову успішність. Ми почали дивитися на те, що саме тестують наші тести. Наші показники покриття впали з 94% до 67%. Це була найчесніша метрика, яка у нас була.
Зелений пайплайн не означає, що ваш код працює. Це означає, що ваші тести пройшли. Це різні речі.
Найнебезпечніші баги — це ті, про які ваш пайплайн каже, що все гаразд.
Запитайте себе наступне:
- Чи ловлять мої тести баги, чи просто підтверджують роботу моків?
- Чи справді мої інтеграційні тести щось інтегрують?
- Якщо я приберу всі моки, скільки тестів все ще пройде успішно?
- Я вимірюю покриття чи впевненість?
Пайплайн, який ніколи не падає, не є надійним. Він просто не протестований.
Джерело: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj
