CODEWITHSUNDEEP
c#unit-testing
TBone
TBone

Reputation: 441

TDD - 100% Coverage for methods that wrap SQL

I've just finished reading "Professional Test-Driven Development with C#" and have been trying to find a way to achieve 100% coverage in my code. It's all good until I hit a repository class that is filled with methods implemented something like this:

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

I've been thinking about this for some time, and have not been able to find an answer on the internet that answers this question directly.

My gut feeling is that without the last bit I mentioned, this method can't be unit tested. How should I be viewing this problem?

Upvotes: 1

Views: 512

Answers (2)

Elad Lachmi
Elad Lachmi

Reputation: 10561

The way I see it, if you do actual data access, you are going in to integration testing and leaving the realm of unit testing. I personaly prefer to keep SQL inside the data access layer only, i.e. a single layer before the DB itself and then I test everything up to that point. In my view a method named ReadMyContracts should already have the correct SQL for accessing the data and should only receive (and pass on) the isCondition parameter.

That`s just MHO.

Upvotes: 0

Zdeslav Vojkovic
Zdeslav Vojkovic

Reputation: 14591

First let me say that I believe that achieving 100% coverage makes no sense at all and doesn't prove anything.

That being said, I typically use some layer between DB and business logic - some simple mapper (PetaPoco, Dapper, OrmLite) or, rarely, a full blown ORM (NHibernate).

In cases where I need integration tests against a DB, these tools allow me to run the same queries against a test DB (e.g. an in-memory SQLite DB) instead of 'real' DB server.

With regard to your concern that "the tests are slow and have a significant increase in maintenance." you should bear in mind that these are not unit tests anymore - these are integration tests and they can't be as fast as unit tests.

Upvotes: 6

Related Questions