Unit testing on code that uses the Database [closed]

Answer 1

If you're trying to test the data access code, you'll need a mocking framework. In the following link you can see a unit testing databases video tutorial

Answer 2

Spring has test classes that are transactional. Seed the test data, run the tests, roll them back. It's as if you were never there.

Answer 3

In my database testing practice I used NUnit and before whole sequence of tests is executed database was installed and populated with test data. Certainly this process was not really fast but what prevents you from doing other work while tests are running.

Answer 4

I usually use two approaches.

The code that depends on the database abstraction layer works with IoC and is therefore easily testable with mocks/stubs. You have an IDataAccess or IRepository interface and you test the interactions of your code against it.

The code that actually works against the database (say a class implementing IDataAccess) is tested on its own, usually performing round-trips to the database (insert-retrieve-update-retrieve-delete). Before running every test case the database is recreated or emptied to avoid test cross-talk. This leads to tests requiring a few minutes to run instead of a few seconds, but in my opinion it's important to test the actual database you will use in production. Using a replacement such as in-memory SQLite is not a good choice because it's too different from, for instance, SQL Server.

Answer 5

Depends on the case, but on legacy systems where I wan't to stub out the database I often introduce an interface, lets say IFooDBManager that has methods that return ADO.Net entities, like data tables or data sets. Of course it doesn't have to be an interface, but it could be a virtual method for example. Then, in my tests, I use a small API with a fluent interface that I built myself a long time ago, I use this for creating data sets and tables and filling them with test values so that I can return them from my fakes.

The fluent interface looks something like this:

return DataTableBuilder.Create()
    .DefineColumns("a, b")
    .AddRow().SetValue("a", 1).SetValue("b", 2).DoneWithRow()
    .AddRow().SetValue("a", 10).SetValue("b", 20).DoneWithRow()
.Table

As I said, this is just one of the approaches I use, and this is mainly for legacy systems where I don't want to introduce new dependencies on frame works and such. This is however a technique I haven't seen a lot of other people use so I thought it'd be worth mentioning.

EDIT: I forgot to clarify that this is for stubbing out the database, so the interaction with the database is not tested in this case. The actual interaction will take place in the concrete implementation of IFooDBManager, to test that something else completely is needed.

Also, not all methods on such an interface returns things of course, there are also methods for writing to the database and these I usually test by interaction testing in RhinoMocks where I set expectations on these methods.