テストが実行される場所

自動テストは通常、スクリプトを手動で実行するか、 テスト フレームワーク（テストランナーとも呼ばれる）のヘルパーを使用して、 テストです。ただし、必ずしもスクリプトを手動で実行しなければならないとは限りません。 さまざまな方法でテストを実行して、フィードバックや 開発ライフサイクルのさまざまなポイントで 自信を持てます

前提条件のスクリプト

通常、ウェブ プロジェクトには構成ファイル（package.json ファイル）があります。 npm、pnpm、Bun などで セットアップされますこの構成ファイルには、 ヘルパー スクリプトを利用できます。これらの ヘルパー スクリプトには、プロジェクトのビルド、実行、テストの方法を含めることができます。

package.json 内に、説明を取得する test というスクリプトを追加する必要があります。 テストの実行方法を学びましたnpm や同様のコードを使用する場合、 「テスト」ツール特別な意味を持つスクリプトです。 このスクリプトで、例外をスローする単一のファイルを指定するだけで済みます。 たとえば node tests.js のような形式ですが、 確立されたテストランナーです

テストランナーとして Vitest を使用している場合は、 package.json ファイルは次のようになります。

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

このファイルで npm test を実行すると、Vitest のデフォルトのテストセットが 1 回実行されます。イン Vitest（デフォルトでは「.test.js」で終わるファイルがすべて検索されます）または 実行してください。ご利用の 場合によって、コマンドが若干異なる場合があります。

広く普及しているテスト フレームワークである Vitest を使用することにしました。 実例を見ていきます。詳しくは、 この決定は、テストランナーとしての Vitest で行うことができます。 ただし、テストのフレームワークとランナーは、 共通言語を持つ傾向があります。

手動テスト呼び出し

自動テストを手動でトリガーする（npm test （前の例など）は、コードベースに積極的に取り組んでいるときに実用的になる可能性があります。 機能の開発中に機能のテストを作成すると、 どのように機能すべきかということです。ここでは、 テスト駆動開発（TDD）です。

通常、テストランナーには短いコマンドがあり、それらを呼び出して 保存時にテストを再実行するウォッチャー モードを利用できる場合もあります。 できます。これらはすべて新機能の開発中に役立つオプションです 新しい機能やテスト、またはその両方を簡単に記述できるように設計されています。 迅速なフィードバックを提供しますたとえば、vitest はデフォルトではウォッチャー モードで動作します。 vitest コマンドは、変更を監視し、検出されたテストを再実行します。水 テストの作成中は、このウィンドウを別のウィンドウで開いたままにしておくことをおすすめします。これにより、 テストを作成する際に、そのテストに関するフィードバックを迅速に受け取れます。

一部のランナーでは、コード内でテストを only とマークすることもできます。コードが only テストを含めると、テストの実行時にこれらのテストのみがトリガーされます。 テスト開発が迅速かつ容易になりますたとえすべての テストは短時間で完了するため、only を使用するとオーバーヘッドを削減でき、 作業中の機能やテストと無関係なテストの実行に集中できます。

小規模なプロジェクト、特にデベロッパーが 1 人しかいないプロジェクトの場合は、 コードベースのテストスイート全体を定期的に実行する習慣を身につけたいとお考えかもしれません。 これは、テストの規模が小さく、テストが短時間で完了する 数秒以上かかる可能性があるため、 次に進みます

presubmit または review の一部としてテストを実行する

多くのプロジェクトでは、コードベースが正しく機能しているかを main ブランチにマージし直す必要があります。初めてテストする場合、 これまでにオープンソース プロジェクトに貢献してきたことから、 pull リクエスト（PR）プロセスの一環として、プロジェクトのすべてのテストが つまり、新しく投稿しても、そのことが できます。

テストをローカルで実行する場合は、プロジェクトのオンライン リポジトリ（ （GitHub などのコード ホスティング サービスなど）は、テストに合格したことに気が付かないでしょう。 テストを presubmit タスクとして実行することで すべてが機能しています

たとえば、GitHub ではこれを「ステータス チェック」と呼んでいます。スペースを通じて GitHub Actions。GitHub Actions は 基本的にはテストの一種です。各ステップが成功しなければならず、 Error など）を指定します。プロジェクトのすべての PR にアクションを適用できます。 また、プロジェクトでは、コードを投稿する前にアクションが渡されることを要求できます。GitHub の デフォルトの Node.js アクションは、ステップの 1 つとして npm test を実行します。

</ph>

コードベースが常に「グリーン」であることを確認するためのテストのアプローチです。 テストを正常に実行できないコードを受け入れないことです。

継続的インテグレーションの一部としてテストを実行する

Green PR が承認されると、ほとんどのコードベースは以下に基づいてテストを再実行します。 以前の PR ではなく、プロジェクトの main ブランチを使用します。この問題は、 すぐに行うことも定期的に（毎時間や毎晩など）行うこともできます。これらの 多くの場合、継続的インテグレーション（CI）ダッシュボードの一部として表示され、 プロジェクトの全体的な健全性を示します。

この CI ステップは、特にコードベースの小規模なプロジェクトでは冗長に思えるかもしれません。 テストは審査で合格です。そのため、変更が行われると合格となります。ただし、 必ずしもそうとは限りません。正常に機能した後でも、テストが突然失敗する場合がある 緑色の結果を出力できます。これには、次のような理由が考えられます。

• 競合状態とも呼ばれる複数の変更が「同時に」受け入れられましたが、 それらが微妙ながらも検証されていない方法で相互に影響し合う状況です。
• テストが再現できない、または「不安定」であるどちらも Google Cloud 環境で コードを変更せずに失敗します
  • これは、コードベースの外部のシステムに依存している場合に発生することがあります。1 つの プロキシ。Math.random() > 0.05 の場合にテストするとします。これはランダムに 5% 失敗します。 できます。
• エンドツーエンドのテストなど、すべての PR で実行するにはコストや費用がかかりすぎる テスト（詳細は自動テストの種類で説明） 常にアラートを発生させることなく 時間の経過とともに停止する可能性があります

こうした問題はいずれも克服できませんが ソフトウェア開発全般について、 学びました。

ロールバックに関する間

継続的インテグレーションの一部としてテストが実行される場合、また、テストが 実行された場合、ビルドが「赤」と表示され、 テストが失敗したことを示す別のステータスです。前述のように この問題は、テストでの競合状態など、さまざまな理由で発生します。 不安定なテストにも便利です

小規模なプロジェクトでは、直感的に危機とみなすかもしれません。停止 問題のある変更をロールバックまたは元に戻し、既知の 必要があります。これは有効なアプローチになる可能性もありますが、次の点に留意することが重要です。 テスト（そしてソフトウェア全般）は、目的達成の手段であり、 できます。目標はおそらくソフトウェアを作成することであり、すべてのテストに合格させることではありません。 代わりに、互換性を破る変更を別のルールでフォローアップすることで、ロール フォワードできます。 修正します。

その一方で、これまで見たり、取り組んだことのある大規模なプロジェクト 永続的に破損した状態にできます。さらに悪いことに、大規模なプロジェクトでテストが不安定で、 アラーム疲れを引き起こすほど頻繁に壊れる 開発者に確認します。これは多くの場合、リーダーが解決すべき存続に関わる問題です。 テストは無効になることもあります 確認します。

この問題をすぐに修正することはできませんが、自信を持って文章を作成できるようになります テスト（スキルアップ）し、テスト範囲を縮小して（簡素化）、 障害を簡単に特定できます。コンポーネント テスト数の増加 または統合テスト（タイプの詳細については、自動化ソリューションのタイプ テスト）を使用すると、 メンテナンスが難しく、手間がかかる大規模なエンドツーエンド テスト 一括で作成できます。

リソース

• 夜間のビルドを利用するメリットは何ですか。

理解度をチェックする