自動テストを開始しており、データ アクセス方法の 1 つをテストしたいと考えています。データベースがレコードを返さない場合のコードの動作をテストしようとしています。
これは単体テストまたは統合テストで行うべきことですか?
ありがとう
1838 次
10 に答える
15
テストコードが実際のデータベースに接続し、テストに合格するために特定のデータの存在（またはデータの欠如）に依存している場合、それは統合テストです。
私は通常、JDBC接続やWebサービスプロキシなど、実際のデータを取得するために「データアクセスメソッド」が使用したコンポーネントをモックアウトして、このようなテストを行うことを好みます。モックでは、「このメソッドが呼び出されたら、これを返す」または「このメソッドがN回呼び出されることを確認してください」と言い、テスト対象のクラスに、実際のコンポーネントではなくモックコンポーネントを使用するように指示します。これは「単体テスト」です。これは、他のコンポーネントがどのように動作するかを正確に宣言したクローズドシステムで、テスト対象のクラスがどのように動作するかをテストしているためです。テスト対象のクラスを完全に分離し、テスト結果が不安定にならず、別のコンポーネントの状態に依存しないことを確認できます。
使用している言語/テクノロジーはわかりませんが、Javaの世界では、この目的でJMock、EasyMockなどを使用できます。
于 2009-02-05T16:16:19.780 に答える
10
価値が追加されたよりも、ユニットとは何か、統合テストとは何かについて議論するのに多くの時間が無駄になったと思います。
私は気にしない。
別の言い方をすれば、私がそれをテストしていた場合、それを行うには 2 つの方法があると思います。ゼロ行を返すデータベースを偽造するか、実際に選択用のデータを持たないデータベースに接続します。有意義なフィードバックを得るのに十分な速度で実行されれば、おそらく最も簡単で実装が簡単なものからテストを開始するでしょう。次に、より高速に実行する必要がある場合、または何らかの利点があると思われる場合は、もう一方を検討します。
たとえば、職場で実際のテスト DB への接続を開始する可能性があります。しかし、ソフトウェアが多くの異なるデータベース (Oracle、PostGres、MySQL、SQL サーバー、および DB) で動作する必要がある場合、または作業中のテスト DB が頻繁に「更新」のためにダウンしている場合は、おそらく「pure/unit」と書くでしょう。完全に孤立して存在するテスト。
老後は、「開発者向け」という言葉と「顧客向け」という言葉をより頻繁に使い、より意味のあるテストを行うようにしています。「ユニット」のような用語を広範囲に使用すると、それについての定義を取得すると、人々がファイルシステムをモックアウトしたり、ゲッターとセッターをモックしたりするようなことをするようになります。
私はこれを強く信じています。私はそれについてグーグルの前に提示しました。
幸運を！それがどうなるか教えてください！
于 2009-05-13T15:53:50.307 に答える
7
私の見解では、スコープに基づいてテストを分類する必要があります。
- 単体テストは、外部の依存関係（ファイルIO、ネットワークIO、データベース、外部Webサービス）なしでスタンドアロンで実行できます。
- 統合テストは外部システムに影響を与える可能性があります。
テストを実行するために実際のデータベースが必要な場合は、それを統合テストと呼び、単体テストとは別にしてください。統合テストと単体テストを組み合わせると、コードの保守性が低下するため、これは重要です。
テストの混合バッグは、新しい開発者がテストスイートを実行するために外部依存関係のヒープ全体を必要とする可能性があることを意味します。データベースに関連しているが、実際にはデータベースが機能する必要がないコードに変更を加えたいと想像してみてください。データベースに関連するテストを実行するためだけにデータベースが必要な場合は、イライラするでしょう。事業。
外部依存関係をモックアウトするのが難しい場合（たとえば、DotNetで、Rhino Mocksを使用していて、外部クラスにインターフェイスがない場合）、外部システムにアクセスするシンラッパークラスを作成します。次に、単体テストでそのラッパーをモックアウトします。この簡単なテストを実行するためにデータベースは必要ないはずなので、データベースは必要ありません。
于 2009-02-05T17:02:52.383 に答える
5
ユニットテストと統合テストの構成について厳格なルールを持っている人（私自身を含む）がいます。
次の場合、テストは単体テストではありません。
- データベースと通信します
- ネットワークを介して通信します
- それはファイルシステムに触れます
- 他の単体テストと同時に実行することはできません
- それを実行するには、環境に対して特別なこと（構成ファイルの編集など）を行う必要があります
これは、実際のリソースプロバイダー（ファイルシステム、データベースなど）ではなく、たとえばモックを使用して単体テストが実行することを区別する1つの方法かもしれません。
統合テストは、システム/アプリケーション層の非常に結合したテストと見なすことができるため、基本はユニットでテストされ、システムの相互運用性が統合テストの焦点になります。
ただし、これらの種類のルールに対する特定の例外を特定できることが多いため、まだ灰色の領域です。
于 2009-02-05T16:29:26.740 に答える
2
重要な質問は「何をすべきか」だと思います。
この場合、単体テストを行う必要があると思います。DB と対話するコードをモックし、信頼できる結果 (行なし) を返すようにします。このようにして、テストは行がないときに何が起こるかをチェックし、DB がその時点で DB にあるものを返すときに何が起こるかをチェックします。テスト。
間違いなく単体テストしてください！
[TestMethod]
public void ForgotMyPassword_SendsAnEmail_WhenValidUserIsPassed()
{
var userRepository = MockRepository.GenerateStub<IUserRepository>();
var notificationSender = MockRepository.GenerateStub<INotificationSender>();
userRepository.Stub(x => x.GetUserByEmailAddressAndPassword("me@home.com", "secret")).Return(new User { Id = 5, Name = "Peter Morris" });
new LoginController(userRepository, notificationSender).ResendPassword("me@home.com", "secret");
notificationSender.AssertWasCalled(x => x.Send(null),
options => options.Constraints(Text.StartsWith("Changed")));
}
于 2009-02-05T16:43:50.643 に答える
1
実際のデータベースがなくても、単体テストとしてテストできると思います。データベースへの実際のインターフェースを使用する代わりに、それをモック/スタブ/偽のオブジェクトに置き換えます（より視覚化されたPDFはここにあります）。
単体テストとして作成するのが難しすぎて、テストが簡単であるというコードをリファクタリングできない場合は、統合テストとして作成することをお勧めします。実行速度が遅くなるため、コードを変更した後はすべての統合テストを実行できない可能性があります（1秒あたり数百、数千を実行できる単体テストとは異なります）が、定期的に実行されている限り（たとえば、継続的インテグレーション）、それらはいくつかの価値を生み出します。
于 2009-02-05T16:26:42.237 に答える
0
これは定義上、単体テストです。特定のパスでコードの単一の分離された要素をテストしています
于 2009-02-05T16:56:25.330 に答える