# Тестування

> Стратегії перевірки та тестування, процеси та тестові сторінки.

---

LLMS index: [llms.txt](/llms.txt)

---

Цей розділ містить стратегії перевірки та тестування, процеси та тестові сторінки, які використовуються для тестування вебсайту та розгортання живих перевірок.

> Цей розділ знаходиться в стадії розробки.

## Тестові твердження {#test-assertions}

### Мета {#goal}

Коли тест завершується невдало, у вихідних даних має бути чітко видно, що саме перевірялося, а також має бути показано чітке порівняння фактичних і очікуваних значень, без довгих рукописних повідомлень.

Наприклад, уникайте:

```js
assert.ok(a === b, `expected ${a} to be ${b}`);
```

Натомість використовуйте:

```js
assert.strictEqual(status, expectedStatus, 'HTTP status');
```

### Настанови {#guidance}

Пункти нижче використовують вбудований механізм `node:test` та API `assert` Node, оскільки саме їх використовують кілька наших тестових наборів. Ті самі ідеї застосовуються в інших тестових фреймворках: віддавайте перевагу твердженням, які дають чіткі відмінності, тримайте контекст помилок коротким і конкретним, і виділяйте спільні допоміжні функції, коли одна й та сама перевірка повторюється.

1. Віддавайте перевагу `assert.strictEqual` замість `assert.equal` для перевірок примітивів, де важлива строгість і якість відмінностей.
2. Додавайте короткий третій аргумент як контекст, наприклад `HTTP status`, `Content-Type`, `Location`, `Request body`.
3. Використовуйте `assert.match`, коли регулярний вираз може чіткіше передати намір, ніж `includes` або ланцюжок `ok` логіки.
4. Розміщуйте спільні допоміжні функції тверджень у модулі, який імпортується тестовими наборами, що їх використовують, розташованими поруч із цими тестами, замість копіювання по файлах. Інші невеликі, лише для тестування утиліти можуть жити в тому ж модулі, коли він залишається сфокусованим (наприклад `assertVaryIncludesAccept` у `netlify/edge-functions/lib/test-helpers.ts`).

---

Section pages:

- [Тестові сторінки](/uk/site/testing/tests/)