Testing Data Access Persist Methods

Question

Hi guys Just wondering if anyone has any ideas on how to test ones data access methods. I have found testing retrieval data access methods is much easier because i can just mock out the ExecuteReader and return a populated dataTable.CreateDataReader(). By doing this I can test to see if my object is populating correctly if a result set is returned.

But how do i translate this to my persist methods (i.e. add, update, delete, etc). What i want to test is whether it populates the command parameters correctly, etc.

Any ideas? Cheers

Answer 1

Mocking is the way to go. With something like Moq you can supply a mocked connection (eg an IDbConnection) to your data access class and test whether the command created by the connection had its parameters correctly set.

I wrote a blog post a while back (see here) which describes a way to mock successive calls to IDbCommand.CreateParameter. Once you've set up your mocked parameters you can verify that their Value and ParameterName properties were set.

Answer 2

We use an in-memory db (hsql) for our unit tests. The setup starts a transaction and the teardown rolls it back. Then you always know the state of the db in your unit tests.

Answer 3

For our o/r mapper framework LLBLGen Pro we use specialized databases for the tests, and different test projects per group of features. So we have a special database for inserts/updates for example, a special database for testing inheritance related actions, a special database for huge sets, a special database for fetching. On top of that, we have separated the unit tests in different projects: fetching oriented, linq provider oriented, insert/update/delete oriented, in-memory stuff oriented, etc.

This way, the tests are maintainable and don't influence eachother. With the special databases, we know what to expect and what to do.

It also depends on what you mean with persistence logic tests of course: if you want to tests the framework-level routines like we do, then mocking is something which is really not that useful: you want to test the real deal in scenario's which cover most, if not all, cases. If you're really talking about testing your code which utilizes framework-level code (e.g. your repository code), then mocking can help, as long as the framework utilized is of course error free. :)