よりシンプルなテスト ピラミッド: テストを最大限に活用する

InfoQ ホームページ アーティクル よりシンプルなテスト ピラミッド: テストを最大限に活用する

この商品は日本語で表示されます

2023 年 4 月 10 日 10 分で読む

による

タイソン・グラッドリー

によってレビュー

マット・キャンベル

開発者は、自動テスト (ユニット、統合、受け入れ、コンポーネント、サービス、エンドツーエンド、UI、データベース、システム、機能、または API) を記述するためにさまざまなラベルを使用します。 これらのラベルはそれぞれ、テストの範囲、テストで実行されるアクションの種類、テストの対象、または対象の協力者を説明する、異なる意味論的な意味を持っています。 通常、これらのラベルのそれぞれが何を意味するかについては意見が一致しておらず、その定義についての議論は無駄になる傾向があります。

どのラベルを使用するか、どのように定義するかについて議論するよりも、「遅い」または「速い」という 2 つの形容詞のいずれかを使用して各テストにラベルを付ける方が役立つことがわかりました。 これらのラベルは、開発者が非生産的な議論をせずにテストを客観的に分類できるようにしながら、テスト スイートの構成を決定するときにも同様に役立ちます。

Java を独自の方法でコーディング、デプロイ、スケールします。Microsoft Azure は、Java アプリ、アプリ サーバー、またはフレームワークのいずれで作業しているかにかかわらず、豊富な選択肢でワークロードをサポートします。 もっと詳しく知る。

テスト ラベルの選択は、テスト スイートの構成に重要な影響を与えます。 開発者はこれらを使用して、特定の動作に対するテストをいつ作成するかを判断し、どの種類のテストを作成するかを判断し、テスト スイート全体のバランスを評価します。 これを誤ると、正確なカバレッジを提供しないか、許容できないコストでカバレッジを提供するテスト スイートが作成されてしまいます。

本番コードの特定の部分のテストをいつ作成する必要がありますか? 私と同じように、エクストリーム プログラミング (XP) またはテスト駆動開発 (TDD) を実践する開発者は、この質問に「常に」と答えることがよくあります。 ただし、すべてのコードを自動的にテストする必要はありません。 提案された各テストについて、まず、テストを作成するコストと利点を比較検討します。

私はテストを書くことを反対しているわけではありません。 実際、ほとんどのテストでは、これは簡単なチェックで、答えは「はい」です。 ただし、このチェックは、特にテストの実行が遅い場合、書き込みが遅い場合、または保守が難しい場合に役立ちます。 このような場合は、いくつかの質問を自分自身に問いかけてください。

設計上の決定によりテストにコストがかかるのでしょうか? コードをリファクタリングしてテストに適したものにすることはできますか? テストは製品コードの最初のコンシューマです。 コードのテストを容易にすると、多くの場合、コードの利用が容易になり、コードベースの品質が向上します。

テスト手法のせいでテストにコストがかかりますか? 別のテスト手法を使用すると、このテストの作成が容易になりますか? コラボレーターの代わりに、フェイクやモックなどのテスト ダブルを使用することを検討してください。 テストに複雑なセットアップが必要な場合は、これをテスト シナリオに抽出し、テスト間で再利用できます。

テストダブルは実際のコラボレーターほどの信頼性を提供しないため、テストダブルを使いすぎないように注意してください。 場合によっては、この信頼性の低下によって、セットアップが容易になったり、テスト期間が短縮されたり、信頼性が向上したりする価値があります。 ただし、テスト ダブルに依存しすぎると、テストが実装に結合され、その結果、テスト スイートの信頼性が低くなり、リファクタリングが阻害される可能性があります。

動作のテストが本質的に難しいため、テストにコストがかかりますか? その場合は、テストしている機能の重要性を考慮してください。 支払い処理に関わる重要な機能であれば、コストをかけてテストする価値があるかもしれません。 それが表示ロジックにおける特殊なエッジケースである場合は、テストを作成するかどうかを再検討する必要があります。

テストは予期せず失敗するためコストがかかりますか? その場合は、それを削除するか、信頼性を高めるために書き直すか、残りのテスト スイートから分離する必要があります。 テスト スイートが有用なフィードバックを提供するには、テストの失敗が望ましくない動作を表すものであると確信する必要があります。 テストが必要であり、予測可能にできないことが判明した場合は、そのテストを、実行頻度の低い別のテスト スイートに移動します。