単体テスト。 クイックスタート-効果的な結果（C ++の例を使用）

参加する代わりに

みなさんこんにちは！ 今日は、テストコードを簡単に、そして喜んで書く方法についてお話したいと思います。 事実、当社では製品の品​​質を常に監視し、高く評価しています。 実際、毎日何百万人もの人々が彼らと一緒に働いており、ユーザーを失望させることは容認できません。 報告期限が来たと想像してください.VLSIの慎重に設計されたユーザーインターフェイスを使用して、慎重かつ喜んで文書を準備し、各桁を再度チェックして、近い将来に税務署の礼儀正しい人々との会合がないことを確認しました。 そして今、マウスを軽くクリックして、切望されている「送信」ボタンをクリックしてください。 アプリケーションがクラッシュし、ドキュメントが破壊され、モニターが熱い炎で燃え、制服を着た人々がすでにしつこくドアをたたき、報告を求めているようです。 これがどのように発生するかを次に示します。







ふー...まあ、私は同意します、おそらく私はモニターに興奮しました;）それでも、発生した状況は、私たちの製品のユーザーが最も好ましい心の状態ではない可能性があります。



そのため、Tensorでお客様の道徳的状態を評価するため、開発した製品を包括的にテストすることが非常に重要です-当社では、これは、ほぼ300人のテスターが製品の品質を監視することによって保証されています。 ただし、開発のすべての段階で品質が管理されるようにします。 そのため、開発プロセスでは、統合、負荷、受け入れテストは言うまでもなく、自動化された単体テストの使用を試みます。



ただし、これまでのところ、インタビューの経験から、誰もがテスト可能なコードを作成するスキルを持っているわけではないことに注意してください。 したがって、テストされたコードの作成の原則について「指で」話し、また、メンテナンスとアップグレードが簡単な単体テストを作成する方法を示したいと思います。



以下に示す資料の大部分はC ++ロシア会議で発表されたので、読み、聞いて、見ることさえできます。

優れた単体テストの特徴

自動実行されるテストを記述する際に最初に対処しなければならないタスクの1つは、外部依存関係の処理です。 外部依存とは、テストされたコードが相互作用するが、それを完全に制御できないエンティティを意味します。 このような制御されていない外部依存関係には、ハードドライブ、データベース、ネットワーク接続、乱数ジェネレーターなどとの対話を必要とする操作が含まれます。



システムのさまざまなレベルで自動テストを実行できると言わなければなりませんが、特に単体テストに関連する問題を検討します。



以下の例の根底にある原則をより明確に理解するために、コードが簡略化されています（たとえば、 const修飾子は省略されています）。 テスト例自体は、 GoogleTestライブラリを使用して実装されます。



統合テストと単体テストの最も重要な違いの1つは、単体テストがすべての外部依存関係を完全に制御できることです。 これにより、単一の単体テストに次のプロパティがあることを実現できます。

• 繰り返します-テストを開始した結果、出力は常に同じ値を返します（常にシステムを同じ状態にします）。
• 安定-昼夜を問わず、テストの開始時刻に関係なく、常に合格または不合格。
• 分離-使用可能なすべての単体テストの開始順序、およびテスト内で実行されるアクションは、単一の単体テストの結果に影響しません。

これはすべて、説明されたプロパティを使用した多くの単体テストの起動を自動化し、実際には単一のボタンを押すだけで実行できるという事実につながります。



優れた単体テストは高速です。 プロジェクトに多数のテストがあり、それぞれの実行が長い場合、すべてのテストの実行にかなりの時間がかかるためです。 これにより、ユニットコードが実行されると、すべてのユニットテストが実行される回数が減るという事実につながる可能性があります。これにより、システムが変更に応答するのにかかる時間が長くなり、導入されたエラーを検出する時間が長くなります。



彼らは、テストアプリケーションを使用する人にとってはすべてがはるかに簡単であると言いますが、私たちにとって、このような高速のターンテーブルを持っていない単なる人間にとっては、それほど甘くないです。 したがって、さらに理解します。

単体テスト。 すべてはどこから始まりますか

単体テストの記述は、名前の選択から始まります。 単体テスト名に対する推奨されるアプローチの1つは、3つの部分で名前を形成することです。



-テストワークユニットの名前

-テストスクリプト

-期待される結果



したがって、たとえば、 Sum_ByDefault_ReturnsZero 、 Sum_WhenCalled_CallsTheLoggerなどの名前を取得できます。 それらは完全な文として読まれるので、テストでの作業が簡単になります。 テスト対象を理解するには、コードのロジックを理解せずに、テストの名前を読むだけで十分です。



ただし、場合によっては、テストコードのロジックを理解する必要があります。 この作業を簡素化するために、ユニットテスト構造は3つの部分で構成できます。



- アレンジの一部-ここでは、テストに必要なオブジェクトを作成および初期化します

- 法の一部-実際にテストアクションを実施

- アサートの一部-ここで取得した結果と参照の比較



テストの読みやすさを高めるために、これらの部分は空の文字列で互いに分離することをお勧めします。 これにより、コードを読んでいる人の方向が決まり、テストで最も関心のある部分をすばやく見つけることができます。



コードのロジックを単体テストでカバーする場合、テストされたコードの各モジュールは次のいずれかのアクションを実行する必要があります。 だから、あなたはテストすることができます：



-結果を返す

-システム状態の変更

-オブジェクト間の相互作用



最初の2つのケースでは、分離のタスクに直面しています 。 これは、テストツールにコードを導入しないことで構成されており、コードを完全に制御することはできません。 後者の場合、 認識問題を解決する必要があります 。 テストされたコードでは使用できない値にアクセスすることで構成されます。たとえば、リモートWebサーバーによるログの受信を制御する必要がある場合です。



テスト可能なコードを作成するには、意図した目的で偽オブジェクトを実装および使用できる必要があります。



偽オブジェクトの分類にはいくつかのアプローチがありますが、テスト済みコードの作成プロセスで解決されるタスクに対応する基本的なものの1つを検討します。



彼女は、 スタブオブジェクトとモックオブジェクトという2つのクラスの偽オブジェクトを区別しています 。 これらは、さまざまな問題を解決するように設計されています。分離問題を解決するスタブオブジェクトと、認識問題を解決するモックオブジェクトです。 最大の違いは、スタブオブジェクトアサート （取得した結果を参照と比較する操作）を使用すると、テストとテストされたコードの間で実行され、モックオブジェクトの使用は分析を前提とし、テストが合格したかどうかを示すことです。



戻り値の分析またはシステムの状態の変化に基づいて作業のロジックをテストできる場合は、そうします。 実践が示すように、モックオブジェクトを使用する単体テストは、スタブオブジェクトを使用するテストよりも作成および保守が困難です。



従来のコードを使用した作業の例について、与えられた原則を考えてみましょう。 図3に示すEntryAnalyzerクラスがあるとします。 1、および私たちはユニットテストで彼のパブリックメソッドAnalyzeをカバーしたいです。 これは、このクラスを変更するか、この方法でその動作を文書化したいという事実によるものです。



コードをテストでカバーするために、外部依存関係を定義します。 私たちの場合、これらの依存関係の2つがあります。データベースの操作とネットワーク接続の操作です。それぞれ、 WebServiceクラスとDatabaseManagerクラスで実行されます 。

class EntryAnalyzer { public: bool Analyze( std::stringename ) { if( ename.size() < 2 ) { webService.LogError( "Error: "+ ename ); return false; } if( false== dbManager.IsValid( ename ) ) return false; return true; } private: DatabaseManager dbManager; WebService webService; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図1 ユニットテストのカバレッジに適さないテストクラスコード



したがって、 EntryAnalyzerクラスの場合、それらは外部依存関係です。 潜在的に、 dbManager.IsValidチェックと最終的なtrueの戻り文の間には、テストが必要なコードが存在する可能性があります。 テストを記述するとき、既存の外部依存関係を取り除いた後にのみアクセスできます。 表示を簡素化するために、このような追加のコードは提供されていません。



次に、外部の依存関係を解消する方法を見てみましょう。 これらのクラスの構造を図に示します。 2。

 class WebService { public: void LogError( std::string msg ) { /* ,     */ } }; class DatabaseManager { public: bool IsValid( std::string ename ) { /* ,      */ } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図2。 ネットワーク接続とデータベースを操作するためのクラス構造



テスト済みのコードを作成するには、特定の実装ではなく、契約に基づいて開発できることが非常に重要です。 私たちの場合、ソースクラスの契約は、セルの名前（ entry ）が有効かどうかを判断することです。



C ++では、このコントラクトはIsValid仮想メソッドを含む抽象クラスとして文書化でき、その本体は定義する必要はありません。 これで、このコントラクトを実装する2つのクラスを作成できます。1つ目はデータベースと対話してプログラムの「本番」バージョンで使用され、2つ目は制御されない依存関係から分離され、テストに直接使用されます。 説明された回路は図に示されています。 3。





図3 データベースとの相互作用への依存を解消するためのインターフェースの導入



データベースの依存関係を壊すことができるサンプルコードを図に示します。 4。





図4 データベースの依存関係を解消するためのクラスの例



上記のコードでは、インターフェイスで指定された機能を実装するメソッドのオーバーライド指定子に注意する必要があります。 これにより、生成されたコードの信頼性が向上します。これは、これらの2つの関数の署名が一致する必要があることをコンパイラーに明示的に通知するためです。



また、抽象クラスデストラクターvirtualの宣言にも注意を払う必要があります。 これが意外で予想外の場合は、 S。Myersの著書「Effective Use of C ++」を読み、熱心に読んでください。特にルール7に注意して読んでください 。

スタブオブジェクトを使用した依存関係の解除

EntryAnalyzerクラスをテストするために必要な手順を検討してください。 前述のように、スタブオブジェクトを使用したテストの実装は、モックオブジェクトを使用するよりもいくらか簡単です。 したがって、まずデータベースへの依存を解消する方法を検討します。



方法1.デザイナーのパラメーター化



まず、 DatabaseManagerクラスのハードコードされた使用を取り除きます。 これを行うために、 IDatabaseManagerなどのポインターの操作に移りましょう。 クラスの動作を維持するには、デフォルトのコンストラクタを定義する必要もあります。このコンストラクタでは、「戦闘」実装を使用する必要があることを示します。 導入された変更と結果の変更されたクラスを図に示します。 5。





図5 データベースの依存関係を解除できるリファクタリング後のクラス



依存関係を実装するには、もう1つのクラスコンストラクターを追加する必要がありますが、ここでは引数が必要です。 この引数は、使用するインターフェイス実装を正確に決定します。 クラスのテストに使用されるコンストラクターを図に示します。 6。





図6 依存関係を注入するために使用されるコンストラクター



これで、クラスは次のようになります（クラスのテストに使用されるコンストラクターは緑色の丸で囲まれています）。





図7 データベースの依存関係を解消するクラスリファクタリング



これで、有効なセル名の処理結果を示す次のテストを作成できます（図8を参照）。

 TEST_F( EntryAnalyzerTest, Analyze_ValidEntryName_ReturnsTrue ) { EntryAnalyzer ea( std::make_unique<FakeDatabaseManager>( true ) ); bool result = ea.Analyze( "valid_entry_name" ); ASSERT_EQ( result, true ); } class FakeDatabaseManager : public IDatabaseManager { public: bool WillBeValid; FakeDatabaseManager( bool will_be_valid ) : WillBeValid( will_be_valid ) { } bool IsValid( std::string ename ) override { return WillBeValid; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図8 実際のデータベースと相互作用しないテストの例



偽オブジェクトのコンストラクターパラメーターの値を変更すると、 IsValid関数の実行結果に影響します。 さらに、これにより、データベースへのアクセスの肯定結果と否定結果の両方を必要とするテストで偽オブジェクトを再利用できます。

コンストラクターをパラメーター化する2番目の方法を検討してください。 この場合、 ファクトリー 、つまり他のオブジェクトの作成を担当するオブジェクトを使用する必要があります。



最初に、同じ手順に従ってDatabaseManagerクラスのハードコードされた使用を置き換えます。必要なインターフェイスを実装するオブジェクトへのポインターの使用に移りましょう。 ただし、デフォルトのコンストラクタでは、必要なオブジェクトを作成する責任をファクトリに割り当てます。



結果の実装を図に示します。 9。





図 9.クラスをリファクタリングしてファクトリを使用し、データベースとやり取りするオブジェクトを作成する



導入されたファクトリクラスを考えると、テスト自体は次のように記述できます。

 TEST_F( EntryAnalyzerTest, Analyze_ValidEntryName_ReturnsTrue ) { DbMngFactory::SetManager( std::make_unique<FakeDatabaseManager>( true ) ); EntryAnalyzer ea; bool result = ea.Analyze( "valid_entry_name" ); ASSERT_EQ( result, true ); } class DbMngFactory { public: static std::unique_ptr<IDatabaseManager> Create() { if( nullptr == pDbMng ) return std::make_unique<DatabaseManager>(); return std::move( pDbMng ); } static void SetManager( std::unique_ptr<IDatabaseManager> &&p_mng ) { pDbMng = std::move( p_mng ); } private: static std::unique_ptr<IDatabaseManager> pDbMng; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図10 テストが実際のデータベースと相互作用しない別の例



このアプローチと以前に検討されたアプローチとの重要な違いは、同じコンストラクターを使用して「戦闘」とテストコードの両方のオブジェクトを作成することです。 ファクトリは、必要なオブジェクトを作成するために細心の注意を払っています。 これにより、クラスの責任範囲を区別できます。 もちろん、あなたのコードを扱う人はこれらのクラスの関係を理解するのに時間が必要です。 ただし、将来的には、このアプローチにより、長期サポートに適合したより柔軟なコードを実現できます。



方法2.「選択およびオーバーライド」



データベースへの依存を解消する別のアプローチとして、「選択と上書き」（抽出と上書き）を検討してください。 おそらく、そのアプリケーションはよりシンプルに見え、そのような感情を引き起こさないでしょう：







その主なアイデアは、1つ以上の関数で「ファイティング」クラスの依存関係をローカライズし、その後継クラスでそれらを再定義することです。 このアプローチを実際に考えてみましょう。



依存関係のローカライズから始めましょう。 この場合、依存関係はDatabaseManagerクラスのIsValidメソッドを呼び出すことです。 この依存関係を個別の関数に分離できます。 変更はできるだけ慎重に行う必要があることに注意してください。 その理由は、これらの変更が既存の作業ロジックを壊さないことを確認できるテストの欠如です。 私たちが行った変更を最も安全なものにするために、関数のシグネチャを可能な限り保持するよう努める必要があります。 したがって、外部依存関係を含むコードを別のメソッドに転送します（図11を参照）。





図11 別のメソッドで外部依存関係を含むコードを削除する



この場合、クラスをどのようにテストできますか？ 簡単です-選択した関数virtualを宣言し、元のクラスから新しいクラスを継承します。ここで、依存関係を含む基本クラスの関数を再定義します。 そこで、外部の依存関係のないクラスを取得しました-そして、テストをカバーするためにテストツールに安全に入力できるようになりました。 図 図１２は、そのようなテストクラスを実装する１つの方法を示している。





図12 依存関係を解除するための「選択とオーバーライド」メソッドの実装



テスト自体は次のように記述できます。

 TEST_F( EntryAnalyzerTest, Analyze_ValidEntryName_ReturnsTrue) { TestingEntryAnalyzer ea; ea.WillBeValid = true; bool result = ea.Analyze( "valid_entry_name" ); ASSERT_EQ( result, true ); } class TestingEntryAnalyzer : public EntryAnalyzer { public: bool WillBeValid; private: bool IsValid( std::string ename ) override { return WillBeValid; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図13 そして、実際のデータベースと相互作用しないテストの別の例



説明したアプローチは実装が最も簡単な方法の1つであり、スキルの蓄積に役立つと便利です。

モックオブジェクトを使用して依存関係を解除する

これで、スタブオブジェクトを使用してデータベースの依存関係を解除できます。 ただし、リモートWebサーバーには未だ依存関係があります。 モックオブジェクトを使用すると、この依存関係を解消できます。



これには何が必要ですか？ ここでは、すでに検討されている方法の組み合わせが役立ちます。 まず、関数の1つに依存関係をローカライズし、それを仮想として宣言します。 関数の署名を保存することを忘れないでください！ ここで、 WebServiceクラスのコントラクトを定義するインターフェイスを選択し、クラスを明示的に使用する代わりに、必要なタイプのunique_ptrポインターを使用します。 そして、この仮想関数が再定義される継承クラスを作成します。 リファクタリング後に得られたクラスを図に示します 14。





図14 リファクタリング後のクラス、ネットワーク相互作用への依存を解消する準備



shared_ptrポインターを、派生クラスで選択したインターフェイスを実装するオブジェクトに導入します。 あとは、コンストラクターのパラメーター化メソッドを使用して依存関係を実装するだけです。 これで、テストできるクラスが次のようになります。





図15 ネットワーク相互作用への依存を解消するテストクラス



そして今、次のテストを書くことができます：

 TEST_F( EntryAnalyzerTest, Analyze_TooShortEntryName_LogsErrorToWebServer ) { std::shared_ptr<FakeWebService> p_web_service = std::make_shared<FakeWebService>(); TestingEntryAnalyzer ea( p_web_service ); bool result = ea.Analyze( "e" ); ASSERT_EQ( p_web_service->lastError, "Error: e" ); } class TestingEntryAnalyzer : public EntryAnalyzer { public: TestingEntryAnalyzer( std::shared_ptr<IWebService> p_service ) : pWebService( p_service ) { } private: void LogError( std::string err ) override { pWebService->LogError( err ); } std::shared_ptr<IWebService> pWebService; }; class FakeWebService : public IWebService { public: void LogError( std::string error ) override { lastError = error; } std::string lastError; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図16。 ネットワーク接続と相互作用しないテストの例



したがって、モックオブジェクトの状態の分析に基づいて、コンストラクターのパラメーター化を使用して依存関係を実装すると、リモートWebサービスが受信するメッセージを見つけることができます。

テストの保守とアップグレードを簡単にするための推奨事項

メンテナンスとアップグレードが簡単な単体テストを構築する方法を考えてみましょう。 おそらく多くの点で、これは自分自身に対する不信によるものです。







最初の推奨事項は、1つのテストで1つの作業結果のみをテストすることです。 この場合、テストが失敗すると、「戦闘」コードのロジックのどの部分がテストに合格しなかったかをすぐに明確に伝えることができます。 1つのテストに複数のアサートがある場合、テストを繰り返し実行し、その後の追加の分析を行わなければ、ロジックが違反された場所を明確に正確に言うことは困難です。



2番目の推奨事項は、パブリッククラスメソッドのみをテストすることです。 これは、実際には、パブリックメソッドがクラスコントラクト（つまり、実行するために引き受ける機能）を決定するという事実によるものです。 ただし、その実装の特定の実装はその裁量に留まります。 したがって、プロジェクトの開発中に、このアクションまたはそのアクションを実行する方法を変更できます。これには、クラスのプライベートメソッドのロジックの変更が必要になる場合があります。 その結果、パブリッククラスコントラクト自体には違反していませんが、プライベートメソッド用に記述された多数のテストが失敗する可能性があります。 それでもプライベートメソッドのテストが必要な場合は、それを使用するクラスでパブリックメソッドを見つけて、それに関するテストを作成することをお勧めします。



ただし、テストが失敗する場合があり、何がうまくいかなかったかを把握する必要があります。 この場合、テスト自体にエラーが含まれていると、かなり不快な状況が発生する可能性があります。 原則として、最初に、テスト自体ではなく、テストされた「戦闘」コードのロジックで失敗の理由を正確に探し始めます。 この場合、障害の原因の検索に多くの時間が費やされる可能性があります。 これを回避するために、テストコード自体ができる限りシンプルになるように努力する必要があります。テストでは分岐演算子（ switch 、 if 、 for 、 whileなど）を使用しないでください。 「戦闘」コードで分岐をテストする必要がある場合は、分岐ごとに2つの個別のテストを作成することをお勧めします。 したがって、典型的な単体テストは、さらにアサートするメソッド呼び出しのシーケンスとして表すことができます。



ここで、次の状況を考えてみましょう。たとえば、100などの多数のテストが記述されたクラスがあります。各クラス内では、テストオブジェクトの作成が必要で、そのコンストラクターには1つの引数が必要です。 ただし、プロジェクトの開発に伴い、状況は変化しました。現在、1つの引数では不十分であり、2つの引数が必要です。 コンストラクターパラメーターの数を変更すると、100個すべてのテストが正常にコンパイルされないという事実につながり、それらを整頓するには、100個すべての場所を変更する必要があります。



この状況を回避するために、私たち全員によく知られているルール「コードの重複を避ける」に従ってください。 これは、テストオブジェクトを作成するためのテストでファクトリメソッドを使用することで実現できます。 この場合、テスト対象オブジェクトのコンストラクターシグネチャを変更するときは、テストプロジェクトの1か所のみで対応する編集を行うだけで十分です。



これにより、既存のテストを健全な状態に維持するのにかかる時間を大幅に短縮できます。 そして、これはすべての面で再び時間を使い果たす状況で特に重要であることが判明するかもしれません。

面白いですか？ もっと深く潜ることができます。

ユニットテストのトピックにさらに詳細に没頭するには、 Roy Osheroveの本「The art of unit testing」をお勧めします。 さらに、テストでカバーされていない既存のコードを変更する必要がある場合にも、非常に頻繁に状況が発生します。 最も安全なアプローチの1つは、最初に一種の「セーフティネット」を作成することです。テストでそれを覆い、必要な変更を加えます。 このアプローチは、 M。Fishersの著書「レガシーコードを使用した効果的な作業」で非常に詳しく説明されています 。 したがって、著者によって記述されたアプローチを習得することは、開発者として、非常に重要で有用なスキルの宝庫をもたらすことができます。



お時間をいただきありがとうございます！ 上記のいずれかが有用かつタイムリーである場合、私はうれしいです。 質問に対するコメントがある場合は、喜んでお答えします。



投稿者：Viktor Yastrebov vyastrebov