Question

I’m trying to write a bunch of unit tests for my classes, most of which are persisted.

In my test class I have a bunch of member variables that contain the data that I’m pushing into my objects which are then created in the repository.

One of the first tests is to create a record in the repository based on the data in the member variables. I then retrieve the UniqueIdentifier from the datastore and set it to one of the member variables.

In one of the later tests, I want to use the UniqueIndentifier to retrieve the record from the datastore but the value is null, as if the value has not been set!

By the way, I’m using MSTest (the default visual studio one).

If anyone has any suggestions I’d greatly appreciate them.

Answer 1

Your tests should each be small, independent, and fast. In theory, unit tests can run in any order, individually, or as a package of tests, and they should not rely on any configuration values (such a connection string).

It sounds like you are trying to persist to a physical data store, and then test that the value actually exists in a later test. Now, you’ve written a test that has a dependency on a previous test. That’s too fragile of a set up.

EDIT 1

I don’t test my repositories. I use NHibby, and I know it works, as long as my configuration is valid. And if my configuration is wrong, I wouldn’t use a unit test to verify this.

I write MVC or WPF/M-V-VM applications. With these styles, it is very easy to write tests against the controller or view model tiers. I will mock out my repositories in a fashion similar to this

[TestMethod]
public void TestThatSomethingHappens()
{
    var repo = new Mock<IRepository>();
    repo.Setup(x => x.Find<Customer>(It.IsAny<int>())).Returns(_somePredefinedCustomer);
    // etc.
}

So, when my code pulls a value from a repository, it will pull out a predefined customer, and that customer was already built in a test setup method (or constructor, if you’re using xUnit). If I want to test what happens when no customer is found, that will be a different test, to I’ll have a .Returns(null), and see what my controller or WinForm does.