Unittesting database library in C# and NUnit

Question

I have recently begun using NUnit and now Rhino Mocks. I am now ready to start using it in a C# project.

The project involves a database library which I must write.

I have read that test should be independent and not rely on each other nor the order of test execution.

So suppose I wanted to check the FTP or database connection. I would write something like

[Test]
public void OpenDatabaseConnection_ValidConnection_ReturnsTrue()
{
  SomeDataBase db = new SomeDataBaseLibrary(...);
  bool connectionOk = db.Open();
  Assert.IsTrue(connectionOk);
}

Another test might involve testing some database functionality, like inserting a row.

[Test]
public void InsertData_ValidData_NoExceptions()
{
      SomeDataBase db = new SomeDataBaseLibrary(...);
      db.Open();

      db.InsertSomeRow("valid data", ...);
}

I see several problems with this:

1) The problem is that the last test, in order to be independent on the first test, will have to open the database connection again. (This will also require the first test to close the connection again, before it's open.)

2) Another thing is that if SomeDataBaseLibrary changes, then all the test-methods will have to change as well.

3) The speed of the test will go down when all these connections have to be established every time the test runs.

What is the usually way of handling this?

I realize that I can use mocks of the DataBaseLibrary, but this doesn't test the library itself which is my first objective in the project.

Answer 1

1: You can open 1 connection before all your tests, and keep it open, until all the tests that use that connection have ended. There are certain attributes for methods, much like the [Test] attribute, that specify when that method should be called:

http://www.nunit.org/index.php?p=attributes&r=2.2.10

Take a look at:

TestFixtureSetUpAttribute (NUnit 2.1) This attribute is used inside a TestFixture to provide a single set of functions that are performed once prior to executing any of the tests in the fixture. A TestFixture can have only one TestFixtureSetUp method. If more than one is defined the TestFixture will compile successfully but its tests will not run.

So, within the method defined with this attribute, you can open your database connection and make your database object global to the test environment. Then, every single test can use that database connection. Note that your tests are still independent, even though they use the same connection.

I believe that this also addresses your 3rd concern.

I am not quite sure how to answer your 2nd concern, as I do not know the extent of the changes that take place in the SomeDataBaseLibrary class.

Answer 2

Just nit-picking, these tests are integration tests, not unit tests. But that doesn't matter right now that I can tell.

1. As @sbenderli pointed out, you can use TestFixtureSetUp to start the connection, and write a nearly-empty test that just asserts the condition of the DB connection. I think you'll just have to give up on the ideal of 1 bug -> 1 test failing here as multiple tests require connecting to the test database. If using your data access layer has any side-effects (e.g. caching), be extra careful here about interacting tests (<-link might be broken).
2. This is good. Tests are supposed to demonstrate how to use the SUT (software under test--SomeDataBaseLibrary in this case). If a change to the SUT requires change to how it's used, you want to know. Ideally, if you make a change to SomeDataBaseLibrary that will break client code, it will break your automated tests. Whether you have automated tests or not, you will have to change anything depending on the SUT; automated tests are one additional thing to change, but they also let you know that you have to make said change.
3. taken care of with TestFixtureSetUp.

One more thing which you may have taken care of already: InsertData_ValidData_NoExceptions does not clean up after itself, leading to interacting tests. The easiest way I have found to making tests clean up after themselves is to use a TransactionScope: Just create one in your SetUp class and Dispose it in TearDown. Works like a charm (with compatible databases) in my experience.

EDIT: Once you have connection logic in a TestFixtureSetup, you can still test connection like this:

[Test]    
public void Test_Connection() 
{
  Assert.IsTrue(connectionOk);
}

One downside to this is that the Exercise step of the test is implicit--it is part of the setup logic. IMHO, that's OK.