SpecFlowと代替テストアプローチ

SpecFlowを使用したテストは、「良いプロジェクト」に必要な技術のリストにしっかりと入っています。 さらに、SpecFlowは動作テストに重点を置いていますが、統合や単体テストでさえこのアプローチの恩恵を受けることができるという結論に達しました。 もちろん、BAとQAの人々は、そのようなテストの作成には参加しなくなり、開発者自身のみが参加します。 もちろん、小規模なテストでは、これによりかなりのオーバーヘッドが発生します。 しかし、むき出しのコードよりも人間のテストの説明を読む方がはるかに楽しいです。





例として、MSTestの通常のタイプのテストからSpecFlowのテストに作り直したテストを示します。

古典的なアプローチ

上記の例は、この記事で説明したい代替アプローチには適用されず、古典的なアプローチを参照します。 この非常に古典的なアプローチでは、テストの「入力」データはテスト自体で特別に作成されます。 このフレーズは、「代替性」の構成要素であるヒントとしてすでに役立ちます。

テスト用のデータの古典的な作成のもう少し複雑な例では、代替案を比較できます：

 Given that I have a insurance created in year 2006 And insurance has an assignment with type 'Dependent' and over 70 people covered
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードのある次の行は、そのような行に対応しています。これを以下のステップと呼びます。

 insurance = new Insurance { Created = new DateTime(2006, 1, 2), Assignments = new List<Assignment>() }; insurance.Assignments.Add(new Assignment { Type = assignmentType, HeadCount = headCount + 1 });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、テストステップの定義には、これらのオブジェクトをステップ間で転送できるコードがありますが、簡潔にするために、このコードは省略されています。

代替案

このアプローチは、私ではなく同僚によって発見され、適用されたことをすぐに述べたいと思います。 ハブとgithubで、彼はgerichhomeとして登録されています 。 私はそれを説明し公開することを約束しました。 まあ、多分、habrの伝統によれば、記事よりも有用なコメントが表示されますが、彼が書いて時間を無駄にしたのは無駄ではなかったことがわかります。

プロジェクトの場合のように、場合によっては、ポータルページを表示するために大量のデータが必要になります。 また、特定の機能をテストするために必要なのはごく一部です。 そして、ページの残りの部分がデータの不足から落ちないように、かなりの量のコードを書く必要があります。 さらに悪いことに、SpecFlowステップをいくつか記述する必要があります。 このように、あなたは望む、望まないということが判明しますが、現時点では必要な部分ではなく、ページ全体をテストする必要があります。

そしてこれを回避するために、データを作成することはできませんが、利用可能なものの中から検索します。 データは、テストデータベース、または一部のAPIのスライスで収集およびシリアル化されたモックファイルにあります。 もちろん、このアプローチは、多くの機能、少なくともこのデータを操作できる部分が既にある場合により適しています。 そのため、テストに必要なデータセットがない場合は、最初に「手動」でテストスクリプトを実行し、データをキャストしてから自動化できます。 既存のコードをテストでカバーする必要がある場合、および/または必要な場合にこのアプローチを使用すると便利です。リファクタリング/リライト/拡張し、機能が壊れることを恐れないでください。



前と同様に、このテストには、2006年に作成され、Dependentタイプの割り当てと70人以上の対象人数を持つInsuranceオブジェクトが必要です。 データベースに保存されている保険には他にも多くのエンティティが含まれており、プロジェクトではモデルが20以上のテーブルを占有していました。 デモンストレーションの一環として、完全なモデルを使用せず、単純化したモデルには3つのエンティティのみが含まれています。

適切な保険を見つけるには、何らかの方法でIEnumerable <Insurance>の形式でソースを特定し、ステップの定義を次のように変更する必要があります。

 insurances = insurances.Where(x => x.Created.Year == year); insurances = insurances.Where(x => x.Assignments.Any(y => y.Type == assignmentType && y.HeadCount > headCount));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、次の手順で、ポータルを開き、HTTP要求行で最初に見つかった保険のIDを渡して、必要な機能を実際にテストする必要があります。 もちろん、これらのアクションの詳細は、このトピックの範囲をはるかに超えています。

検索アルゴリズム

保険が見つかったので、ポータルを開いて、UIの目的のセクションに保険の名前が表示されていることを確認し、今度は他のセクションに必要な依存者の数が表示されていることを確認する必要があります。 ここで問題が発生しますが、このステップで、どの割り当てによって保険がこの条件を満たしているかを正確に調べるにはどうすればよいですか？ たとえば、HeadCountをUIの数と比較するために5つのうちどれを使用する必要がありますか？

これを行うには、「Then」ステップでこの条件を繰り返す必要があり、コードの複製は明らかに悪いです。 さらに、条件の複製もSpecFlowのステップ内にある必要がありますが、これはまったく受け入れられません。

叙情的な余談-プロジェクトの1つで同様のことが既にありました。SSNリストを返すことで人々を探しているSQLクエリがありました（簡単にするために、configから取得します）。 シナリオによると、これらの人々は18歳以上の子供を産む必要がありました。 そしてビジネスの人々は長い間議論し、ほとんど呪い、特定の人が条件を満たした子供を見つけるためにこのリクエストを分解できない理由を理解できませんでした。 彼らは、なぜ2番目のリクエストが必要なのか理解できませんでした。 そして、BAがテストのテキストを書くより明るい未来のアイデアがあるので、ステップで複製が必要な理由を説明することは、この複製を排除するよりもはるかに難しく、これは検索アルゴリズムによって解決される最初のタスクです。

また、前の段落で説明した通常の検索では、2番目のステップを2つのSpecFlowステップに分割することはできません。 これは、アルゴリズムによって解決される2番目の問題です。 このアルゴリズムとその実装について詳しく説明します。

このアルゴリズムは、次の図に概略的に示されています。



検索は非常に簡単です。 ルートエンティティの元のコレクション（この場合は保険）は、IEnumerable <IResolutionContext <Insurance >>として表されます。 自身の条件を満たし、条件を満たした子会社のコレクションを持つ保険のみがそれに該当します。 これらの子エンティティを指定するには、いわゆる Func <T1、IEnumerable <T2 >>型のラムダを持つプロバイダー。

子コレクションにも条件があり、その中で最も単純なものはExistsです。 このような条件では、コレクションが自身の条件を満たす少なくとも1つの要素を持っている場合、コレクションは有効と見なされます。

単純な場合、独自の条件はフィルターであり、タイプFunc <T1、bool>のラムダです。

この図は、すべての条件に適合する2つの保険が見つかった場合を示しています。最初の保険には、条件4に適した一定数のAssignmentオブジェクトと、2つが出てきた一定数のTaxオブジェクトがあります。 また、2番目の保険には、3つの適切な割り当てと4つの税がありました。

そして、これはかなり明白に思えますが、自分の条件に合わなかった保険に加えて、リストには適切な割り当てオブジェクトを見つけられなかった、または適切な税オブジェクトを見つけなかった保険も含まれていません。

赤い矢印は、特定の要素の相互作用のツリーを示しています。 特定のAssignment要素には、最上部への接続が1つだけあり、それを生成した特定のInsurance要素についてのみ「認識」し、要素が配置されているAssignmentsコレクションについても「さらに」Insurancesコレクションについても「認識」しません。親要素のコレクションが存在する場合があります。



ここから、NuGetで開発および公開した実装の使用に関する説明と例を見つけます（最後のリンク）。 同僚が検索アルゴリズムの独自の実装を作成しました。これは主に、登録ネットワークをチェーン、つまり単一のブランチを持つツリーに引き込むという点で異なります。 その実装には、私が持っていないいくつかの機能と、独自の欠点があります。 また、その実装にはいくつかの不必要な依存関係があり、それらは別個のモジュールでの決定をわずかに妨害します。 さらに、ルーフィングは政治的な理由で、ルーフィングは個人的な理由で感じ、彼の決定を公表することに特に熱心ではなく、それは他のプロジェクトで彼を使用することをいくらか難しくします。 自由時間と、興味深いアルゴリズムを実装したいという希望がありました。 一緒にこの記事を書きに行きました。

エンティティとフィルターの登録

最大の粒度を実現するために、手順は次のように分割されています。

 Given insurance A is taken from insurancesSource #1 And insurance A is created in year 2007 #2 And for insurance A exists an assignment A #3 And assignment A has type 'Dependent' #4 And assignment A has over 70 people covered #5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、このような粒度は多少冗長に見えるかもしれませんが、一方で、非常に高いレベルの再利用を達成することができます。 5〜6個のテストを記述した検索アルゴリズムのテストを作成する場合、次のすべてのテストは4分の3が再利用されたステップで構成されていました。



次の構文は、そのようなソースとフィルターを登録するために使用されます。

  context.Register() .Items(key, () => InsurancesSource.Insurances); #1 context.Register() .For<Insurance>(key) .IsTrue(insurance => insurance.Created.Year == year); #2 context.Register() .For<Insurance>(insuranceKey) .Exists(assignmentKey, insurance => insurance.Assignments); #3 context.Register() .For<Assignment>(key) .IsTrue(assignment => assignment.Type == type); #4 context.Register() .For<Assignment>(key) .IsTrue(assignment => assignment.HeadCount >= headCount); #5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで使用されるコンテキストは、定義を含むクラスに注入される（TestingContextコンテキスト）です。 SpecFlowテキストのすべての行には、定義への準拠を示すためにのみ番号が付けられています。これらの行の順序は任意です。 これは、「背景」機能を使用するときに役立ちます。 この登録の自由は、プロバイダーツリーが登録自体ではなく、結果の最初の受信時に構築されるという事実により実現されます。

検索結果の取得

 var insurance = context.Value<Insurance>(insuranceKey); var insurances = context.All<Insurance>(insuranceKey); var assignments = context.All<Assignment>(assignmentKey);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の行は、すべての条件に一致する最初のポリシーを返します。 2007年に作成され、70人がいる少なくとも1つの依存型割り当てがあります。

2行目は、これらの条件を満たすすべてのポリシーを返します。

3行目は、一致するポリシーから一致するすべてのAssignmentオブジェクトを返します。 つまり、結果には不適切なポリシーからの適切なカバレッジが含まれていません。

「すべて」メソッドは同時に、IEnumerable <Insurance>ではなく、IEnumerable <IResolutionContext <Insurance >>を返します。 最後のものを取得するには、抽出フィールド値を選択します。 IResolutionContextインターフェイスを使用すると、現在の親に適した子エンティティのリストを取得できます。 例：

 var insurances = context.All<Insurance>(insuranceKey); var firstPolicyCoverages = insurances.First().Get<Assignment>(assignmentKey);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、T1-key1とT2-key2の任意の2つのペアについて、次の条件が真であることに言及することが重要です-コンテキストT1-key1から、これが変数であるとしましょう

  IResolutionContext<T1> c1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

、T2-key2コンテキストコレクションを取得

 IEnumerable<IResolutionContext<T2>> cs2 = c1.Get<T2>(key2)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

、このコレクションの任意の要素から、T1-key1へのコールバックを作成できます。結果のコレクションには元の要素が含まれます。

 cs2.All(x => x.Get<T1>(key1).Contains(c1)) == true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、c1要素とcs2要素の間では、組み合わせたフィルターに示されているすべての条件が満たされます。

複合フィルター

場合によっては、2つのエンティティのフィールドを比較する必要があります。 そのようなフィルターの例：

  And assignment A covers less people than maximum dependents specified in insurance A
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

条件は、もちろん、他の一部のものと同様に非現実的です。 これが誰にも迷惑をかけないことを願っています。一例は一例です。

そのようなステップの定義：

 context .For<Assignment>(assignmentKey) .For<Insurance>(insuranceKey) .IsTrue((assignment, insurance) => assignment.HeadCount < insurance.MaximumDependents);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフィルターは、ツリーのルートから最も遠いエンティティ（この場合は割り当て）に割り当てられ、実行のプロセスで、赤い矢印を上に移動して保険を検索します（最初の図）。

異なるキーを持つ同じタイプの2つのエンティティがフィルタに参加する場合、それらの間に不等式フィルタが自動的に適用されます。

つまり、.For <Assignment>（ "a"）.For <Assignment>（ "b"）の場合、ラムダ（a1、a2）=>は両方の引数で同じエンティティを取得しません。



ほとんどの場合、3つのエンティティを使用する条件は断片に分割される可能性があるため、フィルターで2つのエンティティを使用できるという事実に限定しました。 技術的な制限はありません。「トリプル」フィルターを自由に追加できます。

コレクションのフィルター

コレクションのいくつかのフィルターは既に配置されており、そのうちの1つ-Existsは既に使用されています。 DoesNotExistおよびEachフィルターもあります。

文字通り、以下を意味します-少なくとも1つの子エンティティがある場合、親エンティティ（この場合は保険）は適格と見なされます-割り当てが適格です。 これは存在するためです。 DoesNotExistの場合-条件に一致する割り当てがない場合、およびEach-この保険のすべての割り当てが条件に適合する場合。

さらに、コレクションに独自のフィルターを設定できます。 例：

 context.ForAll<Assignment>(key) .IsTrue(assignments => assignments.Sum(x => x.HeadCount) > 0);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、適切な割り当てだけがコレクションのフィルターに分類されます。つまり、最初に独自のフィルターを通過した割り当てです。



2番目の例では、2つのコレクションを比較します。

たとえば、SpecFlowテキスト：

  And average payment per person in assignments B, specified in taxes B is over 10$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

および対応する定義：

 context .ForAll<Assignment>(assignmentKey) .ForAll<Tax>(taxKey) .IsTrue((assignments, taxes) => taxes.Sum(x => x.Amount) / assignments.Sum(x => x.HeadCount) > average);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のテスト手法

トリックは、最初に完全に満たされたオブジェクトを準備し、ページ（Webアプリケーションをテストしていることを意味します）がhappy-pathスクリプトを正常に満たしていることを確認し、その後、後続の各テストで同じオブジェクトを使用して何かを1つずつ壊し、ページがユーザーに適切な警告を発行することを確認します。 たとえば、happy-pathに該当するユーザーには、パスワード、メール、アドレス、アクセス権などが必要です。 そして、悪いテストの場合、同じユーザーが使用され、パスワードが破られ、次のテストメールが無効になります。

データを検索するときに同じ手法を使用できます。

 Background: Given insurance B is taken from insurancesSource And for insurance B exists an assignment B And for insurance B exists a tax B Scenario: No assignment with needed count and type Given there is no suitable assignment B Scenario: No tax with needed amount and type Given there is no suitable tax B
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私が引用したテキストは完全ではなく、重要な行のみです。 この例の「背景」セクションでは、ハッピーパスに必要なすべての登録が設定され、特定の「悪い」シナリオではフィルターの1つが反転されます。 ハッピーパステストでは、適切な割り当てと適切な税金がある保険が見つかります。 最初の「不良」テストでは、適切な割り当てがない保険が見つかり、2番目のテストでは、適切な税金がない保険がそれぞれ見つかります。 このような反転は、次のように含めることができます。

 context.InvertCollectionValidity<Assignment>(key);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、特定のキーを任意のフィルターに割り当て、このキーでこのフィルターを反転できます。

失敗した検索ログ

多くのフィルターが指定されている場合、検索が何も返さない理由をすぐに理解することはできません。 もちろん、二分法でこれに対処するのは非常に簡単です。つまり、フィルターの半分をコメントアウトして、どのような変更が行われ、次に半分から半分になるかなどを確認します。 ただし、便宜上、時間コストを削減するために、最後に利用可能なエンティティを無効にしたフィルターをログに出力する機会を与えることにしました。 これは、最初のエンティティが3つのフィルターからエンティティの半分を除外し、2番目のエンティティが後半を除外し、問題が3番目のフィルターに到達しなかった場合、この場合は2番目に指定されたフィルターが印刷されることを意味します。 これを行うには、OnSearchFailureイベントをサブスクライブする必要があります。



それだけです プロジェクトはgithubで入手できますgithub.com/repinvv/TestingContext

完成したアセンブリは、NuGet www.nuget.org/packages/TestingContextで取得できます。