数据测试层的单元测试

Question

I know the question has been asked many many times before, but still I haven't found a good answer, and my take on the issue is slightly different.

I'm looking for a good way to unit test a Data Access Layer, thoroughly, but if possible atomically. I don't want to use the real Database (or a clone) because it would be an integration test, and I want my tests to remain as lightweight and simple as possible.

The DAL is implemented using NHibernate, and the DB is Microsoft SQL Server. unfortunately some of the DAOs will have to be implemented using plain old ADO.Net. And even worse some of the DAO's would have to be a wrapper around Stored Procedures.

Basically, what I want to test, is that the NHibernate mappings make sense, and that the DAO fundamentally works. I want to create a DB in memory based on my NHibernate mappings, Mock all the required Stored Procedures, and then run my unit test's around this database. Inserting and querying using the DAO I'm testing, from the 'Mock' in memory database.

My questions are as follows:

1. Is this a good approach?
2. does anybody have experience with this approach and can share insights?
3. Is there a some framework or a library that can help me with creating the mock in memory database?
4. How can I build these tests to work for an NHibernate based Dao's and ADO.Net based Dao's?
5. How can I create mocks for stored procedures?

Answer 1

Testing around the DAO is always tricky, but if you have logic inside this layer then it is definitely a good candidate for unit testing.

I have found in the past that using an in-memory database for this type of testing works very well - there is a certain amount of setup cost involved (ie to configure the connection and deployment of your own DB schema as part of the tests) but once this is done they tend to work quite nicely. SQLite looks like it could be a good option for you, it looks like it is fairly straightforward to use with NHibernate , and there is also an SQLite provider for ADO.net .

One issue with SQLite for your problem is that it doesn't support stored procedures. I think that your best bet here is to create separate classes that encapsulate the stored procedure calls, and dependency inject objects of these types into your DAO's. That way, you can use standard object mocking to mock out the stored procedure calls.

One final note - if you do have stored procedures in your application that contain any non-trivial logic, then putting some integration tests around these could prove worthwhile (perhaps one test per stored proc that exercises the DAO and the proc deployed in a production like database). Although these will be somewhat painful to create and maintain, I have found these to be very worthwhile in the past - changes to stored procedures were often the source of bugs due to the fact developers rarely tested stored proc changes thoroughly enough.