Evan Dontje

I’m of the opinion that good developers write unit tests. This means when developing against Windows Azure Table Storage, responsible developers will eventually stumble onto the question of how to unit test code written using the Azure SDK. The common answer is to wrap access to table storage in a Repository Object or Query Object. These objects help by abstracting the rest of the code from the nitty gritty details of talking to table storage. Then when unit testing, replace those objects with a test double to keep your code from actually trying to query table storage.

That’s great for the rest of the code, but what about testing the Repository/Query Objects? Integration tests can be used to test the objects against Table Storage, but this is slower and requires more complex test setup/teardown. Others may skip tests, thinking there shouldn’t be much logic to worry about in these objects.

This approach works but I think we can do better. No matter how hard we try, there is always going to be some amount of logic in our data access classes. This is where TechSmith Hyde comes in.

Using TechSmith Hyde to unit test access to Azure Table Storage

The approach that TechSmith Hyde takes is to provide a fake implementation of table storage that implements the same TableStorageProvider base class that the Azure implementation does. This allows the developer to write methods against the generic TableStorageProvider interface, then select the proper test/production implementation with dependency injection. Both classes have consistent behavior (exceptions thrown, error cases, etc.) regardless of the implementation. A simple example is below:

public class UserRepository
{
  TableStorageProvider _table;
  public UserRepository(TableStorageProvider table)
  {
    _table = table;
  }

  public User GetUser(string id)
  {
    return _table.Get<User>("UsersTable", id, id);
  }

  // Other methods ommitted...
}

[TestClass]
public class UserRepositoryTest
{
  [TestMethod]
  public void GetUser_UserExistsInTable_ReturnsCorrectUser()
  {
    var expectedUser = new User{ Id = "123", Name = "Tyler Durden" };

    var table = new InMemoryTableStorageProvider();
    table.Add("UsersTable", expectedUser.Id, expectedUser.Id);

    var userRepository = new UserRepository(table);

    var actualUser = userRepository.GetUser("123");

    Assert.AreEqual(expectedUser.Name, actualUser.Name);
  }
}

As you can see in the simple test above we’re able to test table storage access using an in-memory fake. To support production use, simply inject the Table Storage backed AzureTableStorageProvider implementation instead.

Using Hyde we can test our data access classes, increasing test coverage in our application and allowing us to feel more confident our code does what we think it does.