Тестування

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

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

Категорії тестів

Тестові скрипти в package.json згруповані за домовленостями іменування, які також керують їх автоматичним виявленням:

• test:base виконує основні перевірки (еквівалентно check). У CI вони покриваються окремими робочими процесами перевірки, а не єдиним завданням.
• Складені скрипти test:<слово>-<слово> автоматично виявляються та виконуються разом за допомогою test:compound-tests (а отже, і test:all). Присвоєння скрипту складеної назви — це спосіб включити його до цієї групи, навіть якщо в іншому випадку це самостійна перевірка (наприклад test:local-tools).
• test:public виконує перевірки в tests/public/ (будь-які *.test.mjs там). Вони читають зібраний сайт public/, тому потребують попереднього npm run build і пропускаються, коли public/ відсутній. Додайте перевірку, помістивши *.test.mjs у цю теку; дотримуйтесь конвенції пропуску, коли public/ відсутній. Вони навмисно виключені з test:compound-tests (який не виконує збірку) і натомість запускаються в CI у завданні, яке використовує поточний артефакт збірки.
• Скрипти test:*:live — це опціональні перевірки проти розгорнутого, живого сайту.

Тестові твердження

Мета

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

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

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

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

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

Настанови

Пункти нижче використовують вбудований механізм 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).