Update: I updated the PDF location to one that doesn’t require registration.

There are some really great books out there about unit testing, but I think some of them are trying too hard to be long enough to be considered a “book”. I set out to create a document that fills the gap between the various snippets of information from blog posts, and the comprehensive books on the subject. If you’re interested in something a bit more in-depth, here are some great books on the subject:

• The Art of Unit Testing by Roy Osherove
• xUnit Test Patterns by Gerard Meszaros

The paper currently consists of 5 main sections:

• Why Write Unit Tests?
• Unit Test Mechanics
• Common Unit Testing Strategies
• Designing for Testability
• Advanced Techniques

Here is a more complete snapshot of the current outline:

• Introduction
• Unit Testing & Managers
• What Unit Tests Really Do
• Types of Testing
• Testing Framework
• Test Runner
• Unit Test Structure
• Other Test Attributes
• What is Refactoring?
• Test Driven Development
• Evolving Code
• When Should You Write Unit Tests?
• Test is for Functionality, Not Code!
• The Constraints of Reality
• Interfaces – Quick Overview
• Using a Mocking Framework
• Stubs
• The Test Driven Design Paradox
• Testing Under Pressure
• Extracting Duplicate Logic
• Modular Design Benefits

So what are you waiting for? Go check it out online instantly, you can even download it as a PDF if you like. Is anything missing? Is anything just plain wrong? I’d love to hear your feedback.

Remember, if you want to hear more about unit testing, I’ll be speaking in Northeast Wisconsin Saturday, May 9th.

Want to learn how to write good automated unit tests that are beneficial both to the product/customer and to you as a developer? See an overview of the mechanics of unit testing including the tools and frameworks available. You’ll see examples of how to test existing code, but you’ll also see practical examples of how seemingly un-testable code can be designed so that it can be tested with ease. Learn how test driven development and refactoring will improve the readability of your code, minimize debugging, and speed up development.

If you’re anywhere near the Northeast Wisconsin area, stop in. It’s free!

I’ll be publishing both the presentation and a supporting 25+ page paper shortly, so make sure you’re subscribed to my feed.

Fox Valley Tech is located at:
1825 N. Bluemound
Appleton, WI 54912

IEnumerable vs IQueryable

First, you need to understand the purpose of IEnumerable and IQueryable. IEnumerable defines a stream of objects that can be retrieved sequentially. It’s implemented for nearly every type of list, and it’s an integral part of LINQ. There are now methods included such as “Where” and “Select” that let us filter, sort, and manipulate lists of data in interesting yet simple ways. This can also be referred to as LINQ to objects.

IQueryable inherits from IEnumerable, and is designed to be translatable into a query. IQueryable is typically used to build an expression tree that represents the requested operations. The operations are not actually executed until the expression tree is evaluated and used.

As an example, let’s say I have a database with a table and entities called DateRange. Suppose I cast the DateRange entityset (which implements IQueryable<DateRange>) as IEnumerable<DateRange>. When I call LINQ expressions on that IEnumerable, the underlying query is run immediately, which effectively causes all of the data from that table to be retrieved. If I use IQueryable without casting, my operations get turned into SQL that gets executed when I actually try to iterate through the data (probably using ToList() or foreach). It’s obviously preferable to have the query run in SQL since it can more efficiently filter the data.

The Problem

As I mentioned earlier, I recently starting writing a data access method that started to contain some non-trivial logic. Whenever I see logic, I want to be able to unit test it! I ended up pulling out the logic into its own static method. This method takes in IEnumerable<DateRange>, which can also accept IQueryable<DateRange> (because of the inheritance, you’ll recall). Then, I simply use the AsQueryable method in IEnumerable. This ends up building the needed expression tree that can be translated into a SQL query, but it also lets me test against an in memory collection.

public static DateRange FindRelativeToDate(IEnumerable<DateRange> enumerable, DateTime reference, int periodOffset)
{
	//Build as an expression tree, if possible, otherwise enumerate
	var queryable = enumerable.AsQueryable();

	//Now put in all the logic

	var reference2 = reference.AddDays(-1);

	var initialRange = from bp in queryable
		 where reference >= bp.Start && reference2 < bp.End
		 select bp;

	var currentDateRange = initialRange.First();

	if(periodOffset == 0)
		return currentDateRange;

	var newRange = from bp in queryable
		select bp;

	if (periodOffset > 0)
	{
		newRange = newRange.Where(x => x.Start >= currentDateRange.Start);
		newRange = newRange.OrderBy(x => x.Start);
	}
	else
	{
		newRange = newRange.Where(x => x.End <= currentDateRange.End);
		newRange = newRange.OrderByDescending(x => x.Start);
	}

	return newRange.Skip(Math.Abs(periodOffset)).Take(1).FirstOrDefault();
}

In my unit test class, I can define a list of sample data. I took real data from the database to make the tests as close to reality as possible:

private static readonly List<DateRange> _DateRanges = new List<DateRange>
{
	new DateRange {Start = new DateTime(2009, 1, 1), End = new DateTime(2009, 1, 30)},
					new DateRange {Start = new DateTime(2009, 1, 31), End = new DateTime(2009, 3, 01)},
					new DateRange {Start = new DateTime(2009, 3, 2), End = new DateTime(2009, 3, 31)},
					new DateRange {Start = new DateTime(2009, 4, 1), End = new DateTime(2009, 4, 30)},
};

Now, I can easily test the static class I wrote (this is 1 of 9+ real tests):

[TestMethod]
public void FindRelativeToDate_MiddleOfDateRange_ContainingDateRange()
{
	var result = DateRangeRepository.FindRelativeToDate(_DateRanges, new DateTime(2009, 3, 15), 0);
	Assert.AreEqual(_DateRanges[2], result);
}

The only thing that is left to do is wire up the repository method so that it calls my static method. This is a thin wrapper layer that will actually get used in production. If you run profiler, you’ll see that the query expression is being evaluated and converted into an efficient SQL expression.

public DateRange FindRelativeToDate(DateTime reference, int periodOffset)
{
	var ctx = dbEntities;
	return FindRelativeToDate(ctx.DateRangeSet, reference, periodOffset);
}

Limitations/Conclusion

Unfortunately, this method of testing a repository doesn’t scale easily. If you start working with multiple entity sets that are combined with join operations, this technique is next to impossible to use. You’ll see the most benefit when working with a single entity type, and need to test logic in your repository method.

One thing you need to be aware of, is that LINQ to SQL and Entity Framework don’t implement every IQueryable/IEnumerable method. This means that you could potentially make calls on the in-memory collection that will then fail when you use the actual database. Fortunately, these problems can usually be detected fairly quickly.

I created a quick screencast to demonstrate how you go about using this utility. I’m new to screencasts, so don’t expect a high production value!

You can check out the screencast here!

Let me know what you think in the comments!

Developers such as myself often have a tendency to just focus on the class we’re currently working on. Of course I believe this is a good thing, because we all know the importance of focus. However, you should never forget the reason you’re actually writing that class. It is because other code will be consuming it.

There have been far too many instances where I would figure out which pieces I needed to build, and then build each one, from the bottom up. The problem is that I would write the class in the most short-sighted and easiest way possible, which is usually not the best way to use it.

Now, when there is a question of what a class interface should look like, I ask myself what it should look like to make the life of the consumer as easy as possible.

Sometimes we can even take code usability to an extreme. For example, Fluent interfaces, which allow you to chain together multiple calls. In many instances, this makes the code much easier to call, potentially at the expense of making the called code more complicated.

I’ve come up with a simple example to help illustrate. Suppose I need to process a list of x,y coordinates. Here are a couple of potential signatures:

• ProcessData(double[] xData, double[] yData);
• ProcessData(PointF[] points);
• ProcessData(IDictionary<double, double> points);

For now, just ignore the performance implications (they’re going to be linear in this case, or close to it anyway). To choose the correct signature, we need to know who the caller is.

Of course there is a good chance that we’ll have a slight intentional leaky abstraction. In the previous example, we may have been able to use the IEnumerable generic to be more flexible. That’s a topic for another day.

Thankfully, this problem is minimized, although not always eliminated when you follow the single responsibility principle. The better you can follow that principle, the simpler each piece will be. That tends to minimize the potential for the consumer to need the interface to look different than it would naturally be.

Another way to look at your classes from the consumers point of view is to practice test-driven development. In fact, I see this as one of the strongest arguments for test driven design. For each layer in your code, you’re creating code by consuming it before writing it. Every layer acts as an API to the layer above it.

In conclusion, I’m simply recommending that you don’t lose sight of why you’re writing that piece of code. You’re not just writing code for the sake of writing code, you’re writing it to be used!

Here’s the project. I have a successful website called SimpleTracking.com which allows you to track packages using a simple, common user interface. It also allows you to track pages using RSS.

Here is a list of features:

• Supports multiple shippers, including FedEx, DHL, and USPS. The tracking number is resolved to one of them, and if a tracking number could belong to more than one, they are called simultaneously, and the one that returns the results is used.
• Results are cached to avoid overusing the shippers servers
• Errors are handled appropriately

I boiled the design into a tree of classes:

To greatly simply the design, I decided that each module would implement a common interface. After all, they all take in a tracking number, and return tracking data. Here is the ITracker interface:

public interface ITracker
{
	TrackingData GetTrackingData(string trackingNumber);
}

Simple enough? Every class in the diagram above implements the same interface. If I want to add additional functionality, such as logging for example, I can simply add a class to the chain, and implement the same interface.

Now I can wire it up with Spring.NET:

<object name="postUtility" type="YTech.ShipperInterface.Tracking.Http.PostUtility, YTech.ShipperInterface" />

<!-- The trackers that actually do the work -->
<object name="uspsTracker" type="YTech.ShipperInterface.Usps.Tracking.UspsTracker, YTech.ShipperInterface">
	<constructor-arg ref="postUtility" />
	<!-- Code removed for readability... -->
</object>
<object name="fedexTracker" type="YTech.ShipperInterface.FedEx.Tracking.FedexTracker, YTech.ShipperInterface">
	<constructor-arg ref="postUtility" />
	<!-- Code removed for readability... -->
</object>
<object name="dhlTracker" type="YTech.ShipperInterface.Dhl.Tracking.DhlScreenScrapeTracker, YTech.ShipperInterface">
	<constructor-arg ref="postUtility" />
</object>
<object name="simulationTracker" type="YTech.ShipperInterface.Tracking.Simulation.SimulationTracker, YTech.ShipperInterface" />

<!-- Combine all of the other trackers into one stream -->
<object name="multiTracker" type="YTech.ShipperInterface.Tracking.MultiTracker, YTech.ShipperInterface">
	<constructor-arg>
		<list element-type="YTech.ShipperInterface.Tracking.ITracker, YTech.ShipperInterface">
			<ref object="simulationTracker" />
			<!-- Order these by popularity -->
			<ref object="fedexTracker" />
			<ref object="uspsTracker" />
			<ref object="dhlTracker" />
		</list>
	</constructor-arg>
</object>

<!-- Cache the upstream tracking data -->
<object name="cacheTracker" type="YTech.ShipperInterface.Tracking.CacheTracker, YTech.ShipperInterface">
	<constructor-arg ref="multiTracker" />
</object>

<!-- Handle errors by logging them, and returning a special ErrorTrackingData object -->
<object name="MainTracker" type="YTech.ShipperInterface.Tracking.ErrorHandlerTracker, YTech.ShipperInterface">
	<constructor-arg ref="cacheTracker" />
</object>

Now in my code, this is all I have to do:

var ctx = ContextRegistry.GetContext();
var tracker = (ITracker)ctx.GetObject("MainTracker");
var td = tracker.GetTrackingData("my tracking number");

Every piece I’ve written is fully testable. I even created a class that posts data to a remote web server, and returns the response. This allows me to completely test the tracker classes. They don’t care if they’re hitting against a real server, or an in memory request/response mock class.

I have nearly 100% test coverage, and making changes to the site is a breeze.

The next step is to convert the actual web project to an MVC project so that I can unit test the actual page functionality.

Hopefully I’ve given a good example of how inversion of control can be a really good thing. Have any more questions about the architecture? Feel free to leave a comment.

Note: I haven’t replaced the code on the live SimpleTracking.com site yet, but I plan on upgrading in the next couple of weeks.

The prevailing philosophy in regards to unit testing is writing your tests before your code. In practice, this happens a lot less than it should. Why should we write our unit tests first?

• Writing your unit tests first makes you design pieces of your software from the clients perspective. After all, you’re writing your code to be consumed. The code itself is not important, it’s what it does for other code.
• Unit tests are meant to test functionality, NOT code! That means if you write your unit tests after the fact, you’re probably not focusing on the functionality. You might be trying to come up with edge cases that might not even matter to the client. It’s harder to come up with good unit tests after the code is written, because you’re not necessarily looking at it from the clients perspective, or from the perspective of the required functionality.

There are two valid ways to increase code coverage:

• Write additional tests – This only makes sense if you forgot to write the test initially. Since you’re tests are verifying functionality, why don’t you already have a test for this particular piece of functionality?
• Remove the untested code – In a perfect world, this is what you would always do. After all, your tests verify that your code has a certain set of functionality. If you have untested code, that code isn’t needed. Why keep code you don’t need?

Here is the basic process I recommend:

1. Come up with a rough design in your head
2. Write unit tests to test a required piece of functionality
3. Write the code to provide that functionality
4. Verify that the unit tests pass, fix the code as necessary
5. Refactor as necessary
6. Run a code coverage tool, and get as close to 100% as possible using one of the methods I mentioned previously.
7. Go to #2 and repeat as necessary

This article was inspired by the Google App Engine. Using the Django framework for database access is stupidly simple. They’re able to focus on getting something done, which is good enough in a lot of cases. Not every project has to be an N-Tier enterprise application.

Primarily, I write eCommerce websites. Consider the following diagram, which gives you a rough idea of how I’ve traditionally structured my applications:

Notice that a lot of code is being tested. The sweet side of me likes unit tests, but the wheat part of me is telling me to simplify code when possible to minimize the need for unit tests. I’ve traditionally wanted a lot of unit tests at the data access layer because it tends to be a source of a lot of issues due to it’s complexity. It’s complexity is a result of impedance mismatch.

Code that is a good candidate for unit testing:

• Logic/utility/static functions
• Code that will be used in a lot of places, and has a well defined contract
• Code that needs the highest levels of reliability

Now consider what happens when we use LINQ and the ADO.NET Entity Framework. The impendence mismatch has been minimized because the entity framework has automatically written our model code to match the database. It has also been my experience that the queries that are not trivial are usually not re-used. In other words, query complexity is inversely proportional to the frequency of re-use.

The end result is that our code has been greatly simplified. Now our unit tests can focus on the business logic. We’ll actually have more time for unit testing, which should lead to more stable code where it is needed most.

Sure, our UI will contain what are basically database queries. The fact is that many pages simply need a specific set of data that will populate a drop down list for example. I know that it might give people a bad feeling (as it does to myself), but I think it’s something we need to get over. If you want to test the page, in most cases you can just run it, and see that it’s working. In conjunction with a good web testing tool, it would be easy to have high levels of reliability.

Obviously there are a lot of places where this is a bad idea. I’m certainly not condoning a complete lack of a data access layer for every application. I’m applying the 80/20 rule. Places it might not make sense, or where it’s gray:

• A logic class that needs to make frequent, repeated database calls.
• An application that requires a certain level of testability.
• An application that contains some extremely common queries that may or may not be trivial.

If anyone can think of a better name for the project, please let me know! It’s really hard to convey what it actually does. On the project page, I put these basic steps, which should help make it clear:

1. Run this program to execute a SQL statement
2. Copy the resulting XML into a file in your .NET unit test project
3. Embed the XML file you created
4. In your test code, load the embedded XML, deserialize it back into a DataSet (code coming soon)

As the project matures a little bit, I’ll have better documentation. I may even whip up a video demonstration. It’s not really a fancy tool, but it does come in handy.

For example, let’s say you have a database method that returns a DataSet containing a table of blog post items. You have another method that turns that DataSet into an array of post objects. I know that you’re thinking you should normally use an OR mapper, but this is just an example, so please don’t interrupt me!. This tool lets you create a serialized DataSet that you can use in a unit test, which will reconstitute the DataSet into the exact same thing your database method would have returned. You can now pass in a snapshot of real data into the method your testing. If you ARE using an OR mapper like NHibernate, this probably won’t happen much, but when it does, this tool will come in handy.

My solution was to build a program that acted like SQL Server’s Management Studio, but who’s output is a serialized DataSet. The resulting XML can simply be embedded into your unit test project. In your unit test, you simply deserialize the DataSet XML into a DataSet.

Is anyone interested in me posting the source code and compiled EXE? I’ll have to clean it up a bit, so I wanted to see if there was enough interest, of if it’s something I’ll just keep using in-house.