翻訳は、翻訳に関するいくつかのコメントへの応答として作成されました。 テストを自動的に実行するようにIDEをセットアップします 。 記事を読み、実例を参照すると、さまざまなタイプのテストの違いを感じることができます。これは、テストを1つのヒープに混在させずに正しく構成するのに役立ちます。 各テストは、適切な場所で適切なタイミングで行われます。
-マズロフ
小規模/中規模/大規模/モジュール式/統合/機能/シナリオテストについて耳にすることがありますが、これが何を意味するのかを知っているのは何人ですか？ この記事では、テストの種類に関する私の見解を述べます。
モジュラー/小
ユニットテストから始めましょう。 私が見つけた最良の定義は、非常に高速（1ミリ秒未満）で実行されるテストであり、失敗した場合、エラーの発生場所を特定するためのデバッガーは必要ありません。 定義自体は、テストの内容を制限します。 たとえば、テストで入力/出力（I / O）を実行しないでください。これは、テストが1ミリ秒未満で完了するための条件の1つです。 1ミリ秒の制限は非常に重要です。なぜなら、何かを変更するたびに、できればファイルを保存するたびに、ユニットテストのすべて（数千）を実行したいからです 。 許容できるのは2秒のみで、この2秒間はすべてのテストを実行し、何も中断しないようにします。 これは、ctrl + zを数回押すだけで最近の変更を取り消し、「赤」テストを修正できる場合に便利です。 即時のフィードバックは中毒性があります。 デバッガーが必要ないということは、テスト領域がローカライズされていることを意味します（したがって、テストの名前はユニット、たとえば1つのクラスのテストです）。
単体テストの目的は、コード内の条件付きロジック（ifとループ）を検証することです。 これらは、ほとんどのバグが発生する場所です（ バグ理論を参照）。 そのため、他のテストを行わない場合、単体テストは最初に単純なエラーを検出する最良の方法です。 単体テストを通過したコードがある場合、以下で説明するより高いレベルでテストする方が簡単です。
KeyedMultiStackTest.javaは、 Testability Explorerの優れた単体テストの例です。 各テストがどのように物語を語っているかを感じてください。 これはtestMethodA、testMethodBなどではありません...-スクリプトのようなものです。 通常のテストが最初にどのように行われるかに注意してください。慣れているかもしれませんが、ファイルの終わりに向かって、テストは少し不慣れに見えます。 これは、これらが境界線ケースのテストであり、後で発見したためです。 KeyMultiStack.javaでテストされたクラスの面白い点は、3回書き直したことです。 すべてのテストで動作させることはできませんでした。 アルゴリズムに重大な欠陥があることに気付くまで、テストの1つは常に壊れていました。 その時までには、ほとんど動作するプログラムがあり、それはバイトコード分析プロセスの重要なクラスでした。 システムに非常に基本的なものを埋めて、ゼロから書き直す必要があるとき、どう感じますか？ すべてのテストが成功するまで、処理に2日かかりました。 その後、アプリケーション全体が稼働し続けました。 これがいわゆる「うん！ 瞬間」は、単体テストがどれほど優れているかを認識する瞬間です。
各クラスには適切な単体テストが必要ですか？ 一般的に、いいえ。 多くのクラスは直接テストされませんが、他のクラスをテストします。 通常、単純な値オブジェクトには単体テストがありません。 しかし、テストの欠如と不完全なテストカバレッジを混同しないでください。 すべてのクラス/メソッドをテストする必要があります（テストカバレッジ）。 テスト感染（TDD）している場合、これは血流にあります。
中/機能
そのため、単体テストの助けを借りて、各クラスが必要なことを個別に実行することを確認しました。 しかし、それらが一緒にうまく機能することをどのように知っていますか？ これを行うには、プログラムの作業バージョンにあるように関連するクラスを結合し、それらの相互作用の主な方法を確認する必要があります。 タスクは、ifsまたはloopsが機能するかどうかをチェックするのではなく、クラスインターフェイス間のコントラクトを制御することです。 機能テストの良い例はMetricComputerTest.javaです。 各テストの入力はテストファイルの内部クラスであり、出力はClassConst.javaであることに注意してください。 出力を取得するために、いくつかのクラスは互いに対話します。バイトコードの解析、実行パスの分析、最終コストが受け入れられるまでの実行コストの計算です。
クラスの多くは2回テストされます。 上記の単体テストを使用し、機能テストを2回実行します。 ユニットテストを削除しても、機能テストはコードを壊した変更を検出すると確信していますが、ブレークを修正するためにコードのどの部分を登る必要があるのかはわかりません。テストで。 機能テストが失敗し、ユニットテストが成功すると、デバッガーを準備する必要が生じることがあります。 問題箇所が見つかったら、1）バグの内容を理解していることを証明し、2）バグが再発するのを防ぐのに役立つ単体テストを追加します。 このような単体テストは、 KeyedMultiStackTest.javaの最後にある奇妙なテストの外観を説明しています。 これらは、最初にテストを書いたときには考えていなかったものですが、 KeyedMultiStack.javaからクラスのエラーのソースをデバッグおよび検出するのに何時間もかけてオンにする必要がありました。
メトリックの計算は、Testability Browserの機能のほんの一部です。 テストする必要がある機能はまだあります。 機能テストは、アプリケーション全体の単一のエンティティを形成する関連クラスのテストと考えることができます。 ブラウザの類似エンティティの一部を次に示します。Javaバイトコード解析、Javaコード解析、C ++コード解析、メトリックの計算、3種類のレポート、およびヒント用のエンジン。 それらはすべて、相互作用し、共同テストを必要とするクラスの一意のセットに対応しています。 ほとんどの場合、これらのセットは互いに独立しています。
大/受け入れ/風景
ifs、ループ、インターフェイスの相互作用を除いて、他に何をテストする必要があります。 考えられるエラーには別のクラスがあります。 システムコンポーネントを誤って結合する可能性があります。 たとえば、レポートの代わりにnullを渡したり、解析用のjarファイルへのパスを誤って指定したりできます。 これらは論理的なバグではなく、拘束力のあるバグです。 幸いなことに、バインディングバグは簡単に再現可能であり、通常は例外が伴います。 受け入れテストの例はTestabilityRunnerTest.javaです。 テストがアプリケーション全体の動作をどのようにテストし、多くのアサートチェックがないかを確認してください。 それらの多くは必要ありません-その前に、すべての機能が動作することを既に見て、コンポーネントが接続されているそれらの少数の場所をチェックするだけです。
---------------------------
translated.by/you/software-testing-categorization/into-ru/trans
(): Software Testing Categorization (http://googletesting.blogspot.com/2009/07/software-testing-categorization.html)
: © mazurov (Alexander MAZUROV).
UPD1 ：テストに関するシリーズからの新しい翻訳： バグに関する私の統一理論