kavachai

For the last couple of months I’ve been doing a lot of unit tests using MSTest framework. Although it is good to have special assertion classes to simplify verification of strings and collections names picked my framework developers are not very good as for me.

These classes are named StringAssert and CollectionAssert. Looks good at first glance. But took me some time to figure out they exist.

Lets think about context in which they are used. I’m doing assertions in tests and I definitely know about core assertion class named Assert. Suppose additional classes were named AssertString and AssertCollection. Small change in names would make dramatical change in discoverability. As I start typing for Assert class in IntelliSense I would see them next to core assertion class.

This example demonstrates that developers should think about usage context of classes when naming them.

Simone Chiaretta in his How to simulate RowTest with MS Test post has a good sample of how to use Data-Driven Unit Tests from MS unit test framework to achieve same behavior as with RowTest attribute from other frameworks (like NUnit and mbUnit). I only wish that MS solution would be as simple as original RowTest.

Unit testing a Singleton is not a trivial task because each test needs untouched Singleton object to keep all the tests isolated. One way to achieve this is to recreate underlying singleton object using reflection during test setup or teardown as described by Jonathan de Halleux and Omer van Kloeten.

But I think that a better way is to extract implementation from singleton into a separated class. This way we’ll have a class that contains all the logic to be tested and another class used to wrap it into a singleton.

public class LoadBalancer {
	internal LoadBalancer() {
	}

	// LoadBalancer class implementation goes here...
}

public sealed class LoadBalancerSingleton {
	private static readonly LoadBalancer _instance = new LoadBalancer();

	private LoadBalancerSingleton() {
	}

	public static LoadBalancer Instance {
		get {
			return _instance;
		}
	}
}

Using InternalsVisibleTo attribute in this assembly we can allow test project to perform needed unit testing. Although technically it is possible to create another instance of the LoadBalancer class inside this assembly comments on constructor and common sense should prevent such a situation.

So to my mind it’s a good alternative to reflection approach.