何を何をテストするかではなく、何をテストするかは、すべてのチームにとって重要な質問です。テストは目的達成のための手段であり、コードベースのさまざまな部分でテストの優先順位を決めることは、困難な場合があります。
優先順位を付ける最良の方法は、コードベースとチームの目標に基づいて決定します。ただし、多くのコード カバレッジを持つ小規模なテスト（単体テストなどのテストピラミッドの下部）を大量に作成するのに時間と帯域幅はかかりませんが、必ずしもプロジェクトの全体的なリスクが軽減されるわけではありません。
アプリ、ウェブサイト、ライブラリの主なユースケースを検討することで、最初に何をテストするかを選択できます。たとえば、サイトの重要な部分（ユーザー エクスペリエンスを支えるコア コンポーネント）のコンポーネント テストを作成します。たとえば、ユーザーが時系列データをアップロードして管理できるサイトのデベロッパーは、ユーザーがそれらのタスクを実行するさまざまな方法を想像してテストする必要があります。
優先順位付けのもう 1 つのアプローチは、最も多くの情報を得ることです。コードベースに「危険な」部分、レガシー部分、または書き方の悪い部分がコードベースの中にあり、チームの誰も取り組んでいない部分がある場合、それを中心にテストを構築し、さらに無視するか、修正のためにリファクタリングする前に、動作の一貫性を高めると便利です。これは、すでに断絶されているけれどもデータセンターを収容している建物のための足場のようなものだと考えてください。
次元数
テストのピラミッドというコンセプトを導入しましたが、テストは 1 つの次元（小さな範囲の単純な単体テストから、複雑で広範なテスト（単体テスト、統合テスト、エンドツーエンド テスト）までの流れ）しか示されない傾向があります。
ただし、可能なテストタイプの長いリストの中には、複雑さのレベルを表すものではなく、テストの目標や手法を表すものもあります。たとえば、スモークテストは別のカテゴリのテストであり、それ自体は単体テスト、エンドツーエンドテスト、その他のテストになりますが、テスト対象のプロジェクトが有効状態にあるという全体的な信頼性をテスターに与えることを目的としています。ビジュアル テストは、小さなコンポーネントやサイト全体に適用することもできます。
コードベースには固有の要件があります。たとえば、コードベースでは 1 つの機能に合わせ、さまざまなタイプのテストを作成して正しく機能させることが、はるかに重要な場合があります。テストを必要とする新機能が単一のコンポーネント、機能、またはアプローチであることはめったになく、プロジェクトへの影響は広く、さまざまな規模で分散される可能性があります。
テストの優先順位は、ビジネスニーズによっても異なります。高度に技術的なシステムでは、固有のアルゴリズムが正しく機能することを確認するために複雑な単体テストが必要になる場合があります。一方、高度なインタラクティブ ツールは、複雑なタップ入力が正しいレスポンスを引き出すことを確認するビジュアル テストやエンドツーエンド テストに重点を置いています。
テストのアプローチ
規模に関係なく、コードベースのユースケースのテストに集中してください。ユーザーがプロジェクトの任意の部分をどのように使用するかを想像してください。これは、単一のコンポーネント、下位レベルの機能、大まかなエンドツーエンドのユースケースなどを表します。（テストでテスト対象のコードと適切にやり取りできない場合、あらゆる規模で抽象化の不備が明らかになることもあります）。
各テストケースには明確に定義された目標があることが重要です。大規模な「キャッチオール」テストは、テスト以外のコードのように扱いにくい場合があります。
テストドリブン開発の側面
テストドリブン開発（TDD）は、少なくとも最初は失敗することを前提としたテストを作成するという点で、スケールやタイプに関係なくテストを行う独自の手法です。これは手動テストと自動テストの両方に適用できます。達成したい目標を記述し、現在のソリューションまたはコードに欠けているものを確認し、失敗したテストをソリューションに向けたガイダンスとして使用します。
もちろん、架空のアプリケーションやコンポーネントで、構築を始める前に考えられるすべてのシナリオをテストすることは有用ではありません。TDD の役割はコードベースが複雑になる場合に役立ちます。
TDD はバグを修正する際にもおすすめの方法です。バグの再現ケースをコード化できる場合は、自動テストに導入できますが、最初は失敗します。バグを修正すると、テストに合格し、手動での確認なしで修正が成功したかどうかを判断できます。
不透明なボックスとクリアボックス
これは、システムのあらゆる部分をテストする方法です。たとえば、クラスのパブリック インターフェースを使用する場合など、内部が不透明である場合、内部を調べることはできません。
特に理由がない限り、不透明ボックステストから始めることをおすすめします。これにより、コンポーネントがどのように使用されているかに基づいてテストを設計し、コンポーネントの仕組みに気を取られないようにします。コードパスの「公開」インターフェースのみに依存している場合（必ずしもユーザーに公開されているとは限りませんが、コードの他の部分に対しても公開されている可能性があります）、テストで変更が検出されるという前提で、コードのリファクタリングと改善を行うことができます。
「クリアボックス」コードをより不透明なものに変換する 1 つの方法は、状態を他のシステムと緊密に結合するのではなく、コードの依存関係の抽象化や状態を監視するためのコールバックなどの構成可能な要素を導入することです。これにより、コードがより分離され、「テスト」バージョンを提供できるようになります。また、コードが他のシステムとやり取りする場所をモックアップすることもできます。