# テスト

> チェックとテストの戦略、プロセス、テストページ。

---

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

---

このセクションには、ウェブサイトのテストやデプロイ後のライブチェックで使用されるチェックとテストの戦略、プロセス、テストページが含まれています。

> このセクションは作成中です。

## テストカテゴリ {#test-categories}

[`package.json`](../build/npm-scripts/) 内のテストスクリプトは、自動検出にも使われる命名規則によってグループ化されています。

- **`test:base`** はコアチェックを実行します（`check` と同等）。
  CI では、単一のジョブではなく専用のチェックワークフローでカバーされます。
- **複合 `test:<word>-<word>`** スクリプトは自動検出され、`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`** スクリプトは、デプロイ済みのライブサイトに対するオプションのチェックです。

## テストアサーション {#test-assertions}

### 目的 {#goal}

テストが失敗した場合、出力は何がチェックされていたかを明確にし、長い手書きのメッセージなしに実際の値と期待される値の差分を明確に示すべきです。

たとえば、以下のような書き方は避けてください。

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

かわりに、以下のように書いてください。

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

### ガイダンス {#guidance}

以下のポイントでは、Node の組み込みの `node:test` ランナーと `assert` API を使用しています。
これは、いくつかのテストスイートで使われているためです。
同じ考え方は他のテストフレームワークにも当てはまります。
タイトな差分を生成するアサーションを優先し、失敗時のコンテキストは短く具体的に保ち、同じチェックが繰り返される場合は共有ヘルパーを抽出してください。

1. プリミティブチェックでは、厳密性と差分の品質が重要な場合、`assert.equal` よりも `assert.strictEqual` を優先してください。
2. 短い第三引数をコンテキストとして追加してください。
   たとえば `HTTP status`、`Content-Type`、`Location`、`Request body` などです。
3. 正規表現で意図をより明確に表現できる場合は、`includes` や連鎖した `ok` ロジックではなく `assert.match` を使用してください。
4. 共有アサーションヘルパーは、それを使用するテストスイートがインポートするモジュールに入れ、そのテストと同じ場所に配置し、ファイル間でコピーペーストしないでください。
   その他の小さなテスト専用ユーティリティも、モジュールが焦点を保っている限り同じモジュールに配置できます（たとえば `netlify/edge-functions/lib/test-helpers.ts` 内の `assertVaryIncludesAccept`）。