Покриття та метрики якості

Мета

Мета метрик - не просто “досягти %”, а гарантувати стабільність і впевненість у коді.
Ми вимірюємо покриття, щоб:

• контролювати, що основна логіка перевірена тестами;
• виявляти «сліпі зони» після рефакторингу;
• запобігати регресіям перед релізом.

Типи метрик

Метрика	Опис
Lines coverage	частка рядків коду, виконаних під час тестів
Statements coverage	усі оператори JS, виконані хоча б раз
Functions coverage	кількість викликаних функцій
Branches coverage	охоплення умовних гілок (if, switch, тернарні оператори)
Mutation score (опційно)	якість тестів через ін’єкцію помилок (mutation testing)

Основна увага: branches і functions — саме вони відображають логічну повноту тестів.

Порогові значення (coverage thresholds)

Категорія	Мінімум	Ціль
Чисті утиліти / бізнес-логіка	90%	100%
Кастомні хуки	85%	90%
UI-компоненти	70%	80%
Загальний проєкт	80%	85%

Конфігурація покриття у Vitest

vitest.config.ts

test: {
  coverage: {
    provider: 'v8',
    reportsDirectory: 'reports/coverage',
    reporter: ['text', 'html', 'lcov', 'json-summary', 'cobertura'],
    lines: 80, functions: 80, branches: 75, statements: 80,
    exclude: [
      '**/e2e/**',
      '**/stories/**',
      '**/*.d.ts',
      '**/msw/**',
      '**/fixtures/**',
      '**/factories/**',
      '**/.next/**',
      '**/dist/**',
      '**/build/**',
    ],
  },
}

Tip

HTML-звіт (reports/coverage/index.html) зручно відкривати локально --- він показує проблемні файли й рядки.
Cobertura-репорт (reports/coverage/cobertura-coverage.xml) використовується GitLab для відображення в Merge Request.

Контроль у CI

GitLab job:

gitlab-ci.yml

unit:test:
  stage: test
  image: myorg/vitest-env:node20
  script:
    - pnpm vitest run --coverage
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - reports/coverage
      - reports/junit-unit.xml
    reports:
      junit: reports/junit-unit.xml
      coverage_report:
        coverage_format: cobertura
        path: reports/coverage/cobertura-coverage.xml

Автоматичні гейти якості

1. Pipeline fail, якщо покриття нижче порогу (--coverage.enabled + перевірка звіту).
2. Merge Request widget показує % coverage.
3. Якщо покриття ↓ після PR - рев’юер може вимагати додати тести або аргументувати виняток.
4. Опціонально - використання SonarQube / Codecov / Coveralls для історії трендів.

Рекомендації щодо покриття

• Підтримуй високу якість тестів, а не лише відсотки.
  100% рядків не означає 100% логіки.
• Звертай увагу на гілки умов (branches) - це найінформативніша метрика.
• Для великих компонентів використовуй логічні групи тестів замість одного довгого кейсу.
• Візуальний репорт (html) - найкраще місце для пошуку пропусків.
• Не виключай файли з покриття без аргументу.

Виключення з покриття

• Ігноруємо цілі файли, якщо:
  • це barrel (index.ts) без логіки;
  • це type-only файл (*.d.ts);
  • це UI wrapper без поведінки;
  • це mock/factory/fixture.
• Ігноруємо окремі рядки тільки коли інший шлях неможливий:

/* istanbul ignore next */
console.warn('Unreachable code');

Звітність у MR

• MR повинен показувати:
  • ✅ JUnit-результати (reports/junit-unit.xml)
  • ✅ Coverage widget з Cobertura
• Рев’юер перевіряє:
  • покриття не зменшилось суттєво;
  • критичні зміни мають тести;
  • PR не ігнорує coverage без причини;