1

「C# を使用したプロフェッショナルなテスト駆動開発」を読み終えたばかりで、自分のコードで 100% のカバレッジを達成する方法を見つけようとしています。次のように実装されたメソッドで満たされたリポジトリクラスに到達するまでは、すべて問題ありません。

public IEnumerable<MyDataContract> LoadConditional(bool isCondition)
{
   const string QUERY = @"SELECT ...fields... FROM MyData WHERE [IsCondition] = @IsCondition";
   return DataAccessor.ReadMyContracts(QUERY, isCondition); // something, something...
}

私はこれについてしばらく考えていましたが、インターネット上でこの質問に直接答える答えを見つけることができませんでした.

  • SQL関連のビジネスが別のアセンブリに存在することを示唆するものを読みました。私はこれを必要としませんし、そこに行かなければならないとは思いません。これは、コード カバレッジから見ると、かなり表面的な変更です。

  • 単体テスト用にデータベースを接続できることを読みました (これは以前に行ったことがあります)。しかし、これはまあまあ… わからない、気分が悪い。テストは遅く、メンテナンスが大幅に増加します。

私の直感は、私が言及した最後のビットがなければ、このメソッドは単体テストできないということです。この問題をどのように見る必要がありますか?

4

2 に答える 2

6

最初に言っておきますが、100% のカバレッジを達成することはまったく意味がなく、何の証明にもなりません。

そうは言っても、私は通常、DB とビジネス ロジックの間のレイヤーを使用します。単純なマッパー (PetaPoco、Dapper、OrmLite) や、まれに本格的な ORM (NHibernate) を使用します。

DB に対する統合テストが必要な場合、これらのツールを使用すると、「実際の」DB サーバーではなく、テスト DB (インメモリ SQLite DB など) に対して同じクエリを実行できます。

「テストが遅く、メンテナンスが大幅に増加する」という懸念について。これらはもはや単体テストではないことに注意してください。これらは統合テストであり、単体テストほど高速ではありません。

于 2013-03-11T14:07:33.287 に答える
0

私の見方では、実際のデータ アクセスを行うと、統合テストに入り、単体テストの領域を離れることになります。個人的には、SQL をデータ アクセス レイヤー内のみに保持することを好みます。つまり、DB 自体の前の単一レイヤーであり、その時点までのすべてをテストします。私の見解では、という名前のメソッドはReadMyContracts、データにアクセスするための正しい SQL を既に持っている必要があり、パラメーターのみを受け取る (そして渡す) 必要がありisConditionます。

それはただのMHOです。

于 2013-03-11T14:10:13.977 に答える