unit-testing - テストコードの重複を避ける方法

Question

私は単体テストを作成しました。外部リソースが必要な場合は、偽物を使用して処理します。

これまでのところ、すべて順調です。今、私は他のテストフェーズに直面しています。主に、データベースなどの実際の外部リソースに対してユニットテストメソッドを繰り返したい統合です。

では、ユニット対統合テスト用のテストプロジェクトを構築するための推奨事項は何ですか? ユニットと統合のために別々のアセンブリを好む人がいることを理解していますか?

2 つのアセンブリ間で共通のテストコードを共有するにはどうすればよいでしょうか。すべての抽象テストクラスを含む 3 番目のアセンブリを作成し、ユニットと統合を継承させる必要がありますか? 私は最大限の再利用性を探しています...

Dependency Injection (StructureMap) について多くのノイズを耳にします。特定のユニット + 統合テストセットアップでそのようなツールをどのように利用できますか?

誰かが知恵を共有できますか？ありがとう

score 1 · Accepted Answer

2つを物理的に分離する必要はないと思います。適切な解決策は、Microsoft.TeamFoundation.PowerTools.Tasks.CategoryAttribute をテストの上に配置して、通常のテストと統合テストを識別することです。テストを実行する場合 (MSBuild を使用する場合でも)、関心のあるテストのみを実行することを決定できます。

または、それらを個別の名前空間に配置することもできます。

score 1 · Accepted Answer

セットアップおよびティアダウンフェーズで実行されるコードの場合、基本クラスのアプローチがうまく機能します。統合テストの場合、単体テストの機能を適切にパラメータ化された非テストメソッド (できれば別の名前空間に配置) に抽出し、これらの "共通" メソッドを単体テストと統合テストの両方から呼び出すことができます。単体テスト、統合テスト、および一般的なメソッドを個別の名前空間に配置するだけで十分であり、追加のアセンブリは必要ありません。

score 0 · Accepted Answer

1つのアプローチは、複数のテストコンテキストで使用されるヘルパーメソッドを使用して個別のファイルを作成し、そのファイルを単体テストと機能テストの両方に含めることです。変化するパーツについては、依存性注入を使用できます。たとえば、さまざまなファクトリを渡すことができます。単体テストでは、ファクトリは偽のオブジェクトを作成する可能性があり、機能テストでは、実際のオブジェクトをテストデータベースに挿入する可能性があります。

score 0 · Accepted Answer

テストを 2 つのプロジェクトに分割するか、1 つにまとめるかは、クラス/テストの数によって異なります。1 つのプロジェクトにクラスが多すぎると、掘り下げるのが難しくなります。それらを分割する場合、ヘルパー/共通メソッドを 3 番目のアセンブリにスローするか、単体テストアセンブリでそれらを公開して、統合アセンブリがそのアセンブリを参照できるようにすることができます。必要なだけ複雑にします。

score 0 · Accepted Answer

私たちのプロジェクトでは、統合テストと単体テストの両方が一緒にありますが、別々のフォルダーにあります。プロジェクトのレイアウトは、メインセクション (ドメイン、サービスなど) ごとに個別のアセンブリを持つようになっています。各アセンブリには、一致するテストアセンブリがあります。テストアセンブリは、他のテストアセンブリを参照できます。

これは、Services.Test が Domain.Test を参照できることを意味します。これは、Services が実際のコードで Domain.Test を参照するためです。

私たちが持っている再利用可能な部品に関しては

ビルダー - これらは、ドメインで最も重要な/複雑なオブジェクトを作成するための流暢なインターフェースを提供します。これらは、ドメインのメインのテストフォルダーにあります。ドメインテストアセンブリは、他のすべてのテストアセンブリから参照されます。
マザー - データベースにデータを挿入します。必要に応じてオブジェクトをロードするために使用できる、挿入された行の ID を返します。これらは、サービスのメインテストフォルダーにあります。
ヘルパー - これらは、テスト中に小さなことを行う人です。たとえば、IEnumerable を介してコレクションへのアクセスを許可することを好むため、CollectionHelper.AssertCountIsEqualTo<_T>(int count, IEnumerable<_T> collection, string message) を使用して、IEnumerable を List にラップし、カウントをアサートします。私たちのヘルパーはすべて、他のすべてのテストが参照する共通のテストに住んでいます。

IoC コンテナーに関しては、プロジェクトで使用できる場合は、テスト (自動モックによる) だけでなく、一般的な開発においても大きな助けになる可能性があります。テストだけでは少し大変かもしれませんが、contains にすべてを登録することを耳にします。

score 0 · Accepted Answer

いくつかの実験の後、これはテストメソッドを再利用する方法です:

    public abstract class TestBase
    {
        [TestMethod]
        public void BaseTestMethod()
        {
            Assert.IsTrue(true);
        }
    }


    [TestClass]
    public class UnitTest : TestBase
    {
    }

    [TestClass]
    public class IntegrationTest : TestBase
    {
    }

単体および統合テストクラスは、基本クラスのテストメソッドを取得し、それらを 2 つの個別のテストとして実行します。

基本クラスでパラメーター化されたコンストラクターを作成して、モックまたはリソースを注入できるはずです。

このメソッドは、同じアセンブリ内のクラスで使用できると思います。したがって、今のところ、単一のアセンブリアプローチで対応する必要があるようです。

ヒントをありがとう！

score 0 · Accepted Answer

多くの単体テストと対応する統合テストの唯一の違いが、後者が偽物 (モック) ではなく「実際の」リソースを使用することである場合、1 つのアプローチは次のとおりです。

外部からテストクラスでフラグを使用できるようにする is_unit_test
クラスのセットアップで、フラグに応じて偽または実際のリソースを使用できるようにします。たとえば、リアル (クラス DBreal のインスタンス) またはフェイク (クラス DBfake のインスタンス) の DB API を使用する必要がある場合、初期化は次のようになりますif is_unit_test then this.dbapi = new DBfake else this.dbapi = new DBreal。(DBrealそしてDBfake、同じインターフェースに準拠する必要があるので、それをと呼びましょうDBapi。)
テストメソッドの観点からは、ステップ 2 は (手動の)依存関係の挿入に相当します。メソッドは、どのクラスが実際にその依存関係 (DB API) を実装しているかを知りません。むしろ、依存関係は外部からメソッドに注入されます。
テストケースが DB API を必要とする場合、それらは使用しますthis.dbapi
ここで、単体テスト用のフラグを設定し、統合テスト用のフラグを設定せずに、まったく同じテストクラスを実行します。(フラグを使用可能にする方法は、単体テストフレームワークによって異なります。)
明らかに、テストクラスに複数のリソースが必要な場合は、同じアプローチを使用できます。
ifステップ 2 の明示的な記述が見苦しいと感じる人もいます。より「エレガント」にするには、Inversion of Control (IoC) コンテナー (Java では Spring や PicoContainer など) を使用して、代わりに依存性注入を半自動化できます。初期化は次のようになりますthis.dbapi = myContainer.create(DBapi)。
単純なケースでは、IoC コンテナーは物事を複雑にするだけです。コンテナーの構成は簡単ではなく、学習が必要であり、新しいクラスの間違いの可能性があり、追加のファイルが含まれるためです。
ただし、より複雑なケースでは、コンテナーを使用すると作業が簡単になります。リソースの作成にさらに他のリソースが必要な場合、コンテナーはそれらの初期化も処理し、複雑さが実際に低下するためです。しかし、あなたが本当にそこにたどり着かない限り、私はKISSをお勧めします。
別のアセンブリの重要な理由がない限り、それらは KISS に違反します。最初にその理由を待つことをお勧めします。

(依存性注入はクラスレベルでのみ行われると言う人もいることに注意してください。私はこの不当な独断論を考えています。注入は単に、オブジェクトをどのように取得したとしても、呼び出し元が呼び出している正確なクラスを知らないことを意味します。多くの場合、クラスレベルで適用するとより便利になりますが、テストフレームワークによっては、上記のケースで非常に複雑になる場合があります。ただし、一部のテストフレームワークには独自の注入機能があることに注意してください。)

unit-testing - テストコードの重複を避ける方法

7 に答える 7

Related

Reference