14

人々はビジネス アプリケーションのユニット テストをどのように行っていますか? 「テストが簡単」な例を使用した単体テストの例をたくさん見てきました。元。電卓。データ量の多いアプリケーションの単体テストはどのように行われていますか? サンプルデータをどのようにまとめていますか? 多くの場合、1 つのテストのデータが別のテストではまったく機能しない可能性があるため、1 つのテスト データベースだけを使用するのは困難ですか?

コードのデータ アクセス部分のテストは非常に簡単です。テストが難しいと思われるデータに対して機能するすべてのメソッドをテストしています。たとえば、何を投稿するかを決定したり、数値を調整したりするために大量のデータ アクセスが行われる投稿プロセスを想像してください。投稿が適切に行われたことを確認するためのその後のテストに加えて、発生する (そしてテストが必要な) いくつかの中間ステップがあります。成功。これらの手順の一部は、実際にはストアド プロシージャである場合があります。

過去に、テスト データをテスト データベースに挿入してからテストを実行しようとしましたが、正直なところ、この種のコードを記述するのは非常に困難です (そしてエラーが発生しやすくなります)。また、事前にテスト データベースを構築し、変更をロールバックすることも試みました。それは問題なく動作しますが、多くの場所ではこれも簡単には実行できません (多くの人はそれを統合テストだと言うでしょう。それで、どうにかしてこれをテストできるようにする必要があります)。

答えが、これを処理する良い方法がなく、現在はちょっとひどいということである場合、それも知っておくと便利です.

考え、アイデア、提案、またはヒントをいただければ幸いです。

4

6 に答える 6

6

私の自動機能テストは通常​​、次の 2 つのパターンのいずれかに従います。

  • データベース接続テスト
  • 模擬永続層テスト

データベース接続テスト

データベースに接続された自動テストがある場合、通常、すべてのテストに十分なデータを持つ単一のテスト データベース テンプレートを作成します。自動テストが実行されると、すべてのテストのテンプレートから新しいテスト データベースが生成されます。テストは頻繁にデータを変更するため、テストデータベースは常に再生成する必要があります。テストが追加されると、通常はテスト データベース テンプレートにさらにデータを追加します。

このテスト方法にはいくつかの優れた利点があります。明らかな利点は、テストによってスキーマも実行されることです。もう 1 つの利点は、初期テストをセットアップした後、ほとんどの新しいテストで既存のテスト データを再利用できることです。これにより、テストを簡単に追加できます。

欠点は、テスト データベースが扱いにくくなることです。通常、データは一度に 1 つのテストで追加されるため、一貫性がなく、非現実的ですらあります。また、データベース スキーマが大幅に変更された場合、テスト データベースをセットアップした人をののしることになります (これは、通常、自分自身をののしることになります)。

新しいテスト データベースを自由に生成できない場合、このスタイルのテストは明らかに機能しません。

模擬永続層テスト

このパターンでは、テスト ケースと共に動作するモック オブジェクトを作成します。これらのモック オブジェクトはデータベースへの呼び出しをインターセプトするため、プログラムで適切な結果を提供できます。基本的に、テストしているコードがfindCustomerByName()メソッドを呼び出すと、永続化レイヤーの代わりにモック オブジェクトが呼び出されます。

モック オブジェクト テストを使用する利点は、非常に具体的にできることです。多くの場合、モック オブジェクトを使用しない自動テストでは到達できない実行パスがあります。また、大規模でモノリシックなテスト データ セットを維持する必要もありません。

もう 1 つの利点は、外部依存関係がないことです。モック オブジェクトは永続層をシミュレートするため、テストはデータベースに依存しなくなります。これは、どのパターンを選択するかを決定する際の決定要因となることがよくあります。モック オブジェクトは、レガシー データベース システムや厳しいライセンス条件のデータベースを扱う場合に、より多くの注目を集めているようです。

モック オブジェクトの欠点は、余分なテスト コードが多くなることが多いことです。これは恐ろしいことではありません。なぜなら、テストを実行する回数に応じて償却すると、テスト コードのほとんどすべての量が安価になるからです。

于 2008-09-02T01:26:55.253 に答える
2

何をテストしているかによって異なります。ビジネスロジックコンポーネントをテストしている場合、データがどこから来ているかは重要ではなく、おそらく、コンポーネントが実際に呼び出すデータアクセスルーチンをシミュレートするモックまたは手巻きのスタブクラスを使用するでしょう。データ アクセスをいじるのは、データ アクセス コンポーネント自体を実際にテストするときだけです。

それでも、TestFixtureSetUp メソッドで DB トランザクションを開き (明らかに、これは使用しているユニット テスト フレームワークによって異なります)、テスト スイート TestFixtureTeardown の最後でトランザクションをロールバックする傾向があります。

于 2008-09-01T23:42:03.507 に答える
2

モッキング フレームワークを使用すると、ビジネス オブジェクトをテストできます。データ ドリブン テストは、単体テストというよりも統合テストになることが多く、テストの実行前と実行後のデータ ストアの状態を管理する負担と、クエリの接続と実行にかかる時間も伴います。

一般に、ビジネスオブジェクトからデータベースに触れる単体テストを行うことは避けます。データベースのテストに関しては、別の戦略が必要です。

そうは言っても、実際にバックエンド システムを呼び出す必要があるテストの量を制限するだけでは、データ駆動型テストから完全に逃れることはできません。

于 2008-09-01T23:48:52.117 に答える
2

ロールバック ソリューションを使用してこれらの統合テストにアプローチしようとすると、@Phil Bennett のコメントに同意する必要があります。

データアクセスレイヤーの統合テストに関する非常に詳細な投稿がありますこちら

サンプル データ アクセス クラス、基本クラス、サンプル DB トランザクション フィクスチャ クラスだけでなく、サンプル データを含む完全な CRUD 統合テストも示します。このアプローチでは、各テストでデータを制御できるため、複数のテスト データベースは必要ありません。また、テストの完了後、トランザクションはすべてロールバックされるため、DB はクリーンです。

アプリ内のビジネス ロジックの単体テストについては、@Phil と @Mark のコメントも参考にします。ビジネス オブジェクトが持つすべての依存関係をモックアウトすると、アプリケーション ロジックを一度に 1 つのエンティティでテストするのが非常に簡単になるからです ;)

編集：それで、ロジックの事前データベース/ロジックを使用したスト​​アドプロシージャの実行からすべてを検証し、最終的に帰りの検証を行う1つの巨大な統合テストを探していますか? もしそうなら、これを2つのステップに分けることができます：

  • 1 - データがデータ アクセス コードにプッシュされる前に発生するロジックの単体テストを行います。たとえば、いくつかのプロパティに基づいていくつかの数値を計算するコードがある場合、この 1 つの関数のロジックが要求どおりに動作するかどうかのみをチェックするテストを作成します。アプリケーション ロジックのみのこのテストでは無視できるように、データ アクセス クラスへの依存関係をモックアウトします。

  • 2 - 操作されたデータ (ユニット テストした前のメソッドから) を取得し、適切なストアド プロシージャを呼び出すと発生するロジックを統合テストします。これをデータ固有のテスト クラス内で実行して、完了後にロールバックできるようにします。ストアド プロシージャが実行されたら、データベースに対してクエリを実行してオブジェクトを取得します。データに対していくつかのロジックを実行し、期待した値が含まれていることを確認します (ポストストアド プロシージャ ロジック /etc )。

ストアド プロシージャを実行するためにデータベースにエントリが必要な場合は、内部にロジックを含む sproc を実行する前に、そのデータを挿入するだけです。たとえば、テストする必要がある製品がある場合、挿入するサプライヤとカテゴリのエントリが必要になる場合があるため、製品を挿入する前に、サプライヤとカテゴリをすばやくダーティに挿入して、製品の挿入が計画どおりに機能するようにします。

于 2008-09-01T23:54:30.933 に答える
1

メッセージベースのシステム、または入力データの順列が多数ある高度にパラメータ化されたインターフェースを備えたシステムをテストしているように思えます。

一般に、標準 unti テストのすべてのルールは依然として保持されます。

  • テストするユニットは、できるだけ小さく個別に作成してください。
  • テストを独立させるようにしてください。
  • 依存関係を分離するためにコードを因数分解します。
  • モックとスタブを使用して依存関係を置き換えます (データアクセスなど)

これが完了すると、テストから多くの複雑さが取り除かれ、うまくいけば単体テストの適切なセットが明らかになり、サンプル データが単純化されます。

複雑な入力データを必要とするテスト用のサンプル データをコンパイルするための適切な方法論は、直交テストです。こちらを参照してください。

入力メッセージの順列が複数の可能な実行パスを作成できる WCF および BizTalk ソリューションのテスト計画を生成するために、この種の方法を使用しました。

于 2008-09-01T23:44:37.743 に答える
0

同じロジックでさまざまな実行が行われるが、データが異なる場合は、CSV を使用できます。入力には好きなだけ列を、出力には最後の列を使用できます。

于 2008-09-01T23:25:33.640 に答える