First, I give props to they guys at Microsoft who put out the Enterprise
Library. I especially like the data access application block. I do, however,
have one beef with it. Everyone preaches “code to an interface”, and ADO.NET
exhibits this (IDataReader, IDbCommand, etc), but the DAAB doesn’t do this.
Consequently, I can’t stub out a mock object to decouple the DAAB from the code
I’m trying to unit test with NUnit. I then tried NMock to create a dynamic
mock, but the ExecuteReader(string, params object) method wasn’t marked as
virtual. After changing it to virtual and recompiling the source, NMock would
work (it appears most methods were marked virtual, but that some were
overlooked). Not having the interface to stub out _really_ makes TDD
difficult. It forces me to use dynamic mocks (which are more brittle).
Here’s a quick test I whipped up to create a Category class that is a record
in the Categories table of Northwind. Note the use of NMock to get my unit test
to work without the dependency on the DAAB:
Now my test:
I had to use NMock for the Database class, so I just used it for the
IDataReader interface as well (as I further this class, I will modify that to
use a mock stub that implements IDataReader).
This code work and allows me to test the instantiation of my Category object
with the ID of a category.
The data access block is awesome, but I WISH I had an interface to code
against instead of just the abstract class. I guess I’m going to have to insert
the interface myself.
By the way, I attended the webcast about this block this afternoon, and I
have to say that it was the most fun webcast I’ve every attended. The
presenters were in shorts and cutting up and laughing the whole time. 🙂