20

私たちのチームは、データベースにアクセスして結果を検証する数百の統合テストを行っています。すべての統合テスト用に 2 つの基本クラスがあります。1 つは取得のみのテスト用で、もう 1 つは作成/更新/削除テスト用です。取得のみの基本クラスは、TestFixtureSetup 中にデータベースを再生成するため、テスト クラスごとに 1 回だけ実行されます。CUD 基本クラスは、各テストの前にデータベースを再生成します。各リポジトリ クラスには、対応する独自のテスト クラスがあります。

ご想像のとおり、この全体にはかなりの時間がかかります (実行に約 7 ～ 8 分かかり、急速に成長します)。これを CI (CruiseControl.Net) の一部として実行することは問題ではありませんが、ローカルで実行すると時間がかかり、コードをコミットする前にそれらを実行することは実際には禁止されています。

私の質問は、これらのタイプの統合テストの実行を高速化するのに役立つベスト プラクティスはありますか?

SQLite ではサポートされていないデータベース固有の機能 (計算列など) を使用しているため、メモリ内 (SQLite 風) で実行できません。

また、チーム全体がそれらを実行できる必要があるため、それらのインスタンスの接続文字列がすべて同じでない限り、SQL Server Express などのローカル インスタンスでそれらを実行するとエラーが発生しやすくなります。

あなたのショップでこれをどのように達成していますか？

ありがとう！

4

5 に答える 5

16

高速（ユニット）とスロー（統合）テストを個別に保持してください。そうすれば、個別に実行できます。テストフレームワークがテストのグループ化をサポートしていない場合は、統合テストを統合テストのみがある別のモジュールに移動します。

高速なテストは、すべてを実行するのに数秒しかかからず、コード カバレッジが高いはずです。この種のテストにより、開発者は容赦なくリファクタリングを行うことができます。なぜなら、開発者は小さな変更を行ってすべてのテストを実行し、変更によって何も壊れていないことを非常に確信できるからです。

スロー テストの実行には数分かかる場合があり、個々のコンポーネントが正しく連携して動作することを確認します。開発者が、統合テストではテストされているが単体テストではテストされていない何かを壊す可能性のある変更を行う場合、コミットする前にそれらの統合テストを実行する必要があります。それ以外の場合、スロー テストは CI サーバーによって実行されます。

于 2009-08-25T17:48:41.537 に答える
11

NUnit では、テスト クラス (またはメソッド) を属性で装飾できます。

[Category("Integration")]
public class SomeTestFixture{
    ...
}
[Category("Unit")]
public class SomeOtherTestFixture{
    ...
}

次に、サーバー上のビルド プロセスで、すべてのカテゴリを実行し、開発者が利用可能なテスト カテゴリのサブセットを実行することだけを要求するように規定できます。どのカテゴリを実行する必要があるかは、あなたが私よりもよく理解していることによって異なります。しかし要点は、ユニットレベルでテストでき、サーバーが統合テストを処理するということです。

于 2009-08-25T14:49:55.367 に答える
5

私はJava開発者ですが、同様の問題に対処しました。速度 (ネットワーク経由で送信するデータがない) と、この方法では統合テスト データベースで競合が発生しないため、ローカル データベース インスタンスの実行がうまく機能することがわかりました。

この問題を解決するために使用する一般的なアプローチは、構成ファイルからデータベース接続文字列を読み取るようにビルド スクリプトを設定し、環境ごとに 1 つのファイルを設定することです。たとえば、WORKSTATION 用に 1 つのファイル、CI 用に別のファイルを作成します。次に、指定された環境に基づいて構成ファイルを読み取るようにビルド スクリプトを設定します。したがって、開発者ワークステーションで実行されるビルドは WORKSTATION 構成を使用して実行され、CI 環境で実行されるビルドは CI 設定を使用します。

また、データベース スキーマ全体を 1 つのスクリプトから作成できると、非常に役立ちます。したがって、各開発者は、テスト用のローカル データベースをすばやくセットアップできます。この概念を次のレベルに拡張して、データベース セットアップ スクリプトをビルド プロセスに追加することもできます。これにより、データベース セットアップ全体をスクリプト化して、データベース スキーマの変更に対応することができます。

于 2009-08-25T14:46:30.210 に答える
3

テストが最も多くの時間を費やしている場所を特定するために、(タイマーなどを使用して) 何らかの測定を行いましたか?

データベースの再作成が時間のかかる理由であることが既にわかっている場合は、データベースを一度再生成し、トランザクションを使用してテスト間の状態を保持するという別のアプローチがあります。各 CUD タイプのテストは、セットアップでトランザクションを開始し、ティアダウンでロールバックを実行します。トランザクションのロールバックはデータベースを完全に再作成するよりもコストがかからないため、これにより、各テストのデータベース セットアップにかかる時間を大幅に短縮できます。

于 2009-08-25T14:56:33.157 に答える
3

開発環境の一部として、すべての開発マシンで同じ DB 定義が実行されている SQL Server Express インスタンスがあります。Windows 認証では、接続文字列は安定しています。文字列にユーザー名/パスワードはありません。

私たちが本当にやりたいことはまだありませんが、システムをSQL Server Compact Editionで実行できるかどうかを確認することです。これは、SQL Server のエンジンを備えた SQLite のようなものです。次に、それらをメモリ内で実行し、場合によっては並行して (複数のプロセスで) 実行することもできます。

于 2009-08-25T15:05:35.497 に答える