単体テストの場合、CRUD操作をテストするときにデータベースを使用する必要がありますか？SQL liteはこれを支援できますか？どういうわけかメモリ内にデータベースを作成する必要がありますか？
私はmbunitを使用しています。
1220 次
7 に答える
12
いいえ。実際のDBを統合することは、統合テストになります。ユニットテストではありません。
はい、他の方法でDAL / DAOを抽象化（モック）できない場合は、SQLiteやMSSQLCompactなどのインメモリDBを使用できます。
これを念頭に置いて、ユニットテストはDALまで可能ですが、DAL自体は不可能であることを指摘する必要があります。DALは、統合テストで実際のDBのようなものでテストする必要があります。
于 2009-09-27T21:38:03.200 に答える
12
すべての複雑な質問と同様に、答えは次のとおりです:それは依存します:)
一般に、データベースを使用せずにアプリケーションの残りの部分をテストできるように、データ アクセス層をインターフェイスの背後に隠す必要がありますが、データ アクセスの実装自体をテストしたい場合はどうすればよいでしょうか。
場合によっては、ORM などの宣言型データ アクセス テクノロジを主に使用するため、これは冗長であると考える人もいます。
また、データ アクセス コンポーネント自体に、テストが必要なロジックが含まれている場合もあります。これは非常に重要な作業ですが、そのためにはデータベースが必要です。
これを単体テストではなく統合テストと考える人もいますが、私の本では、それを何と呼ぶかはあまり重要ではありません。最も重要なことは、完全に自動化されたテストから価値を引き出すことです。単体テスト フレームワークを使用して、これらのテストを推進します。
しばらく前に、SQL Server でこれを行う方法について書きました。心に留めておくべき最も重要なことは、いくつかの「代表的なデータ」を使用して General Fixture を作成し、すべてのテストでこれを再利用しようとする誘惑を避けることです。代わりに、各テストの一部としてデータを入力し、後でクリーンアップする必要があります。
于 2009-09-28T07:54:17.230 に答える
2
他の人がすでに指摘しているように、あなたが達成しようとしているのは単体テストではなく統合テストです。
そうは言っても、モックとは別に単体テストを好むとしても、統合テストには何の問題もありません。したがって、コンテキストで意味があると思われる場合は、テスト戦略に統合テストを含めるだけです。
さて、あなたの質問に関して、私はDbUnit.NETをチェックします。このツールの.NETバージョンはわかりませんが、Javaバージョンはデータベースと対話するテストに最適です。簡単に言うと、DbUnitを使用すると、テストを実行する前にデータベースを既知の状態にし、テーブルのコンテンツに対してアサートを実行できます。本当に便利です。ところで、このツールを使用しないことにした場合でも、ベストプラクティスのページを読むことをお勧めします。
于 2009-09-28T10:57:29.230 に答える
2
単体テストでは、CRUD 操作をテストするときにデータベースを使用する必要がありますか?
上記の CRUD 操作でインターフェイスを抽出し、モックまたはスタブを介してそのインターフェイスを使用するすべてをテストしたと仮定します。これで、オブジェクトといくつかの SQL をバインドするためのコードを少し含む save メソッドであるコードのチャンクが残ります。
もしそうなら、私はそれを「ユニット」と宣言し、データベースが必要だと言います。理想的には、ベンダー固有の SQL に引っかからないように、少なくともデータベースを適切に表現するデータベースが必要です。
また、エラー状態を強制するためにモックを軽く使用しますが、モックだけで save メソッド自体をテストすることはしません。したがって、技術的にはこれは統合テストかもしれませんが、単体テストの一部としてこれを行います。
編集：質問の2/3を逃しました。ごめん。
sql lite はこれに役立ちますか?
私は過去にメモリデータベースで使用したことがあり、使用したデータベースとライブシステムが何か違うことをしたか、起動にかなりの時間がかかったために噛まれました。とにかく、すべての開発者が開発者ローカル データベースを持っていることをお勧めします。
どうにかしてメモリ内にデータベースを作成する必要がありますか?
データベースではい。私は DbUnit を使用してデータを分散させ、手動で SQL スクリプトを使用してスキーマを最新の状態に保ちますが、SQL スクリプトだけを使用することもできます。開発者のローカル データベースを使用すると、データを維持するためのスキーマとデータセットの両方があるため、メンテナンスが追加されますが、データベース レイヤーが期待どおりに機能していることを確認できるので、個人的には価値があると思います。
于 2009-09-28T10:39:13.153 に答える
0
実際、データベースに接続するテストを作成している場合は、単体テストではなく統合テストを実行しています。
このような操作の単体テストでは、ある種のモックデータベースオブジェクトの使用を検討してください。たとえば、データベースの相互作用をカプセル化するクラスがある場合は、そこからインターフェイスを抽出してから、実際にデータベースに接続する代わりに、単純なメモリ内オブジェクトを使用する継承クラスを作成します。
于 2009-09-27T21:36:53.450 に答える
0
前述のように、ここで重要なのは、テストを実行する前にテスト データベースを既知の状態にすることです。実際の例では、既知のテスト データ セットを再作成するテストの前に実行される SQL スクリプトがいくつかあります。これから、CRUD 操作をテストし、新しい行が挿入/更新/削除されることを確認できます。
于 2009-09-28T11:10:53.887 に答える
0
sqlserver データベースの統合テストを支援するDBSnapshotというユーティリティを作成しました。
データベース スキーマが頻繁に変更される場合は、実際の db インスタンスに対して実際にコードをテストすると役立ちます。SqlLite は迅速なテストに使用されますが (データベースはメモリ内で実行されるため)、実際のデータベースのビルドに対してコードが機能することを確認したい場合には役に立ちません。
データベースをテストするときは、次のようなパターンに従います: データベースをバックアップし、テスト用にデータベースをセットアップし、コードを実行し、結果を検証し、データベースを開始状態に復元します。
上記により、各テストを個別に実行できるようになります。私のDBSnapshotユーティリティは、.net を作成する場合にコードを簡素化します。DbUnit.NETより使いやすいと思います。
于 2009-09-28T19:09:05.653 に答える