ピラミッドのテスト
自動化の観点からのテストの効果的な分布は、ピラミッドの形で表すことができます。
ソフトウェアの機能のほとんどは単純な単体テストでカバーされ、残りの機能についてはより複雑な単体テストが作成されます。 このピラミッドを裏返すと、入り口にさまざまなバグがあり、出口に少数のヘイゼンバッグがある漏斗ができます。 各グループをさらに詳しく考えてみましょう。
- ユニットまたはブロックのテストは、システムの他の部分とは別に、特定の関数、クラス、またはメソッドで動作します。 このため、バグが発生すると、各ブロックを分離し、エラーの場所を特定することができます。 このグループでは、動作テストが区別されます。 実際には、モジュール式のように見えますが、テストコードを記述するための厳格なルールを意味し、キーワードのセットによって規制されています。
- 統合テストは 、アプリケーションコードと外部システムとの相互作用をチェックするため 、 単体テストよりも複雑です。 たとえば、EarlGrey UIテストは、アプリケーションがサーバーAPI応答と対話する方法を追跡します。
- 受け入れテストでは、参照条件で説明されている機能が正しく機能していることを確認します。 これは、テスト環境と特定の起動条件の点で拡張または縮小された大規模な統合テストケースのセットで構成されています。
- UIテストは、アプリケーションインターフェイスがデザイナーまたはユーザーの要求からの仕様をどのように満たしているかをチェックします。 アプリケーションのスクリーンショットがピクセルごとに参照スクリーンショットと比較されるときのスナップショットテストを区別します。 この方法では、2つの画像を比較するには多くのリソースが必要であり、テストサーバーをロードするため、アプリケーション全体を閉じることはできません。
- 手動または回帰テストは、他のすべてのシナリオの自動化後も残ります。 これらのケースは、UIテストを作成する時間がない場合、またはフローティングエラーをキャッチする必要がある場合に、QAスペシャリストによって実行されます。
プロジェクトの開始時および若いチームでは、手動テストに多くの時間と労力がかかり、自動テストはほとんど使用されません。 このため、テストの効率が低下し、それを取り除く必要があります。手動テストから離れて、単体テストの数を増やすためです。
ユニットvs UI
UIテストと比較して、ユニットテストはより高速で、開発時間が短縮されます。 強力なファームや別のデバイスなしで、ローカルで起動できます。 単体テストからのフィードバックは、UIテストからのフィードバックよりも何倍も高速です。 APIまたはXMLファイルの変更から、UIテストは大規模に低下し始め、毎回書き換える必要があります。 このような背景に対して、単体テストの重要な利点は安定性の向上です。
コードカバレッジの観点からすると、単体テストはより効率的ですが、テストを完全にブロックすることはできません。 ユニットテストがベースケースをクローズし、UIテストがより複雑な問題を解決するバランスを常に維持する必要があります。
上位レベルのテストは下位レベルのテストで未解決のバグを通知することを理解することが重要です。そのため、たとえばバトルコードでエラーが発生した場合、対応するユニットテストをすぐに実行する必要があります。 バグが復活すると、最初に発見されたときよりもはるかに不快です。
テストコードの要件
コードの品質と美しさを決定するよく知られているSOLID原則に加えて、テストをプログラミングする際には、速度と信頼性という2つの要件を考慮する必要があります。 これらは、頭字語FIRSTによって結ばれた5つの主要な原則で実現できます。
- F-高速 。 良いテストは、最も速い応答を提供します。 テスト自体、環境へのインストール、および実行後のリソースのクリーンアップには数ミリ秒かかります。
- I-分離されました。 テストは分離する必要があります。 テストは独自に検証を実行し、そのすべてのデータは環境から取得され、他のテストやテストモジュールに依存しません。 この原則に従うことに対する素晴らしいボーナス：テストの順序は重要ではなく、それらは並行して実行できます。
- R-繰り返し可能。 テストには予測可能な動作が必要です。 テストは、繰り返し回数と環境に関係なく、明確な結果を提供する必要があります。
- S-自己検証。 テスト結果は利用可能で、明らかなログに表示されるはずです。
- T-徹底的/タイムリー。 テストは、少なくとも単一のプルリクエストの一部として、コードと並行して開発する必要があります。 これにより、戦闘コードがカバーされ、テスト自体の関連性が保証され、さらに変更する必要がなくなります。
完全に単純化すると、テストは高速で信頼性の高いものになります。 このためには、外部反応と内部タイムアウトの期待がないという同期が重要です。
どのテストがカバーすべきか
TDD（テスト駆動開発）の一環として、今日2つのテストスクールがあります。 シカゴ校では、テストクラスとメソッドが生成する結果に重点が置かれています。 ロンドンの学校では、テストは動作に焦点を当てており、モックオブジェクトの使用を伴います。
たとえば、7と5の2つの数値を乗算するクラスがあるとします。シカゴの学校は、結果が35になることを単純に確認します。どのように学習してもかまいません。 ロンドンの学校では、クラスに存在する内部計算機をロックし、正しいメソッドとデータのセットで呼び出されることを確認し、ロックされたデータを返すことを確認する必要があると言います。 シカゴの学校は、「ブラックボックスで」ロンドンをテストしています。 別のテストでは、両方の方法を使用するのが理にかなっています。
100％のテストカバレッジが不可能な理由
テストを100％のコードでカバーしたとしても、バグがないことを保証することはできません。 そして、100％のカバレッジを達成したいという願望は、作業を妨げるだけです。開発者は、この数字を目指して努力し始め、指標のためにテストを作成します。 テストの品質はカバレッジのレベルでは示されませんが、より単純な事実：最終製品に到達するバグはほとんどなく、見つかったバグをクローズしても新しいバグは表示されません。 カバレッジレベルは、定義によって決定すべきことを示すだけです。コードのカバーされていないセクションがあるかどうか。
テストシリーズの次の資料では、テストコードの品質の要件だけでなく、さまざまなテスト表記とテストオブジェクトの種類の設計、分析に進みます。