1

次の単体テストを行うか、他の種類のテストを行いますか。

データベースの値を更新したいのですが、値を更新した後、データベースが正しい値で更新されていることを確認したいのですが、これは、データベースにクエリを実行して、正しい値が存在するかどうかを判断する必要があることを意味します。単体テスト、データベースに触れることはNO-NOです。

次のようなメソッドを単体テストしたいと思います (db と Update は構成されています)。

public void UpdateValue(int value)
{
   db.Update(value);
}
4

5 に答える 5

3

メソッドがデータベースへの呼び出しを正常に行うことを簡単にテストできます。モッキングは、発生すると予想される呼び出しが実際に発生することに焦点を当てる傾向があります。

のテストが同じ値で呼び出されることを期待していると主張するdbように、テストバージョンに置き換える必要があります。UpdateValuedb.Update(value)

ストアド プロシージャまたは SQL のテストを実行する必要があります (最終的には、C# コードと同じエラーの可能性があります) が、コードの単体テストとは別に実行される可能性があります。ストアド プロシージャ ロジックをテストするための別のテスト プロジェクトがあります。これには物理的なデータベースが含まれるため、分離されて最小限に保たれますが、それでも不可欠であると考えています。ほぼすべてのデータベース スクリプトをテストする段階に到達しましたが、最初は基本的な CRUD コードをテストしなくても問題ありません。条件付きステートメントを備えた SQL はすべてテストされます。

コードを使用してデータベースに保存し、値を再度取得できるかどうかを確認するためにエンド ツー エンド テストを実行する場合、これは定義上、単体テストではありません。@lazyberezovskyが述べているように、これは統合テストです。単体テストは、その単体をテストするために、コードの単体に関するすべての依存関係を削除することを目的としています。

そうは言っても、(私の意見では) 統合テストも行うことが不可欠です。ユーザーがユースケースアクションとしてサインオフしたものをテストするなど、ユースケースに対してそれらを持っています。これは一度に多くのコードを叩きますが、共有状態/副作用コードに苦労するという明確な欠点があります。統合テストでは、テストの大部分がコードのアサーションではなく準備であることがわかります。また、失敗した特定のコードを識別していないこともわかっているため、統合テストの失敗を診断することはより困難です。

統合テストで妥協点を見つけます。私たちのデータベースは DAL インターフェイスを介して供給されます。物理データベースとは対照的に、インメモリ テスト データを提供するために、このインターフェイスをスタブ化するだけです (モッキングとは異なります)。これの 1 つの欠点は、適切なデータベースに対する統合テストを見逃していることです。

于 2012-06-06T14:24:56.823 に答える
1

話しやすいので、より具体的な例を使用します。UpdateValueそれが実際に小売システムのどこかにあり、古い価格をセント単位の新しい値で更新しているとしましょう。

おそらく、あなたのクラスは現在の価格または過去の価格を提供する責任があります - それを と呼びましょうPriceProvider。おそらく、領収書の払い戻し価格を提供する方法を知っているでしょう。おそらく、白い色の冷凍冷蔵庫にさまざまな価格を設定する方法を知っているのでしょう。また、ペンスで提供される新しい価格で価格を更新する方法も知っています。それがその仕事である場合、価格が保存されている場所を知る必要はありません。これは、既に 1 つの責任があるためです (単一責任の原則)。価格を取得する責任を別のものに委任する必要があり、その仕事は、ビジネス要求を、価格が格納されている場所を知っている何かへのパラメーター化された呼び出しに変換することです。

または、クラスがデータベースから価格を取得し、データベースに価格を更新する責任があるかもしれません- a DatabasePriceRepository. 日付とアイテムの価格を検索する方法、または日付とカテゴリの価格リストを取得する方法は知っていますが、検索する理由は気にしません。これがあなたのクラスである場合、それはデータベースに強く結合されています - それは唯一の責任です - そのため、それを嘲笑しても意味がありません。そうしないと、クラスに価値がなくなります。代わりに、統合テストを行ったり、フルスタックのシナリオを書いたり、手動でテストしたりしてテストできます。

私は、Hibernate を使用するプロジェクトで作業し、さまざまなオブジェクトをインスタンス化して構成ファイルをテストしました。それを行うために、Hibernate をメモリ内データベースに結び付けました。それは非常に迅速で、本当に迅速なフィードバックを提供してくれました。また、UI からデータベースまでのエンド ツー エンドのシナリオがあった場所、HTTP 要求でヒットして応答を確認することでいくつかのサービスをテストした場所、およびこれを手動でテストした場所でも働いてきました。

このクラスの単体テストを行うかどうかに関係なく、ある時点で本番環境のデータベースに触れなければなりません。ライブに移行する前にそれをテストしたいと思うでしょう。このクラスを単体テストする場合は、自動化されているかどうかにかかわらず、別の場所で統合テストを実行する必要があります。

于 2012-06-06T15:00:58.993 に答える