Brendan Enrick

Daily Software Development

My Randomly Selected New Year's Resolution

I am quite certain that plenty of resolution randomizers exist, so I will just jump straight in to things. Here is a link to a resolution randomizer created using Silverlight.

Now everyone will feel sorry for my coworkers who have to listen to this, because the random resolution machine said I have to.


Have fun celebrating the coming of the new year everyone.

Comparing Nullable DateTimes

A couple of days ago I was working on some code when I noticed a comparisons of two DateTime? variables. So I wondered what would happen if either or both of those variables had gotten null values. Since I had never tried it before I figured I would just take a couple of minutes and test some things. Since I already had visual studio open I just created a unit test and wrote some code in there to test the behavior. I've not done it in a console application since it is easier for most people to use the console app version of the code.

So the first thing to do is to create a few Nullable DateTime variables. I then wrote a small amount of completely unnecessary code. I did this to assure the readers of this post that the assumption that the Nullable variables' HasValue properties is correct. I then proceed with a bunch of test cases some of which are unnecessary, but I believe they help demonstrate the point.

My task for readers of this post is to try to figure out the results of this code before reading the answer below.

int? lesserDateTime = 1;
int? greaterDateTime = 2;
int? nullDateTime1 = null;
int? nullDateTime2 = null;

if (!lesserDateTime.HasValue || !greaterDateTime.HasValue 
    || nullDateTime1.HasValue || nullDateTime2.HasValue)
    throw new Exception("Something is very wrong here!");

Console.WriteLine("\n lesserDateTime > greaterDateTime = " 
    + (lesserDateTime > greaterDateTime));
Console.WriteLine("\n greaterDateTime > lesserDateTime = " 
    + (greaterDateTime > lesserDateTime));
Console.WriteLine("\n lesserDateTime == lesserDateTime = " 
    + (lesserDateTime == lesserDateTime));
Console.WriteLine("\n lesserDateTime > nullDateTime1 = " 
    + (lesserDateTime > nullDateTime1));
Console.WriteLine("\n greaterDateTime > nullDateTime1 = " 
    + (greaterDateTime > nullDateTime1));
Console.WriteLine("\n lesserDateTime == nullDateTime1 = " 
    + (lesserDateTime == nullDateTime1));
Console.WriteLine("\n greaterDateTime == nullDateTime1 = " 
    + (greaterDateTime == nullDateTime1));
Console.WriteLine("\n nullDateTime1 > greaterDateTime = " 
    + (nullDateTime1 > greaterDateTime));
Console.WriteLine("\n nullDateTime1 > lesserDateTime = " 
    + (nullDateTime1 > lesserDateTime));
Console.WriteLine("\n nullDateTime1 == greaterDateTime = " 
    + (nullDateTime1 == greaterDateTime));
Console.WriteLine("\n nullDateTime1 == lesserDateTime = " 
    + (nullDateTime1 == lesserDateTime));
Console.WriteLine("\n nullDateTime1 > nullDateTime2 = " 
    + (nullDateTime1 > nullDateTime2));
Console.WriteLine("\n nullDateTime2 > nullDateTime1 = " 
    + (nullDateTime2 > nullDateTime1));
Console.WriteLine("\n nullDateTime1 == nullDateTime2 = " 
    + (nullDateTime1 == nullDateTime2));
Console.WriteLine("\n nullDateTime2 == nullDateTime1 = " 
    + (nullDateTime2 == nullDateTime1));


Answer below.
































And just to show that this has to do with Nullable really and not the DateTime part, I did the test with int? also.


This is why you need to be a little bit careful with Nullable types. Make sure that you are always checking the HasValue property when working with Nullable types so you can handle the situation in the desired fashion. If you didn't know or check the type of that variable the results could be disastrous.

Don't make too many assumptions about behavior. I asked a few people what they might expect to get when comparing with the null value, and they guessed that the null would be treated as the default value for the data type. That guess makes a lot of sense, but it is not the case. Notice that every time a null was involved the result was false. The only time this is not the case is when comparing the equality of two null values.

As a final note I will say that if you want to do comparisons of Nullable values I recommend doing the following. Since Nullable's are a little bit special, we need to compare them this way.

Console.WriteLine("\n Nullable.Compare(lesserDateTime, nullDateTime1) = "
    + Nullable.Compare(lesserDateTime, nullDateTime1));
Console.WriteLine("\n Nullable.Compare(nullDateTime1, lesserDateTime) = "
    + Nullable.Compare(nullDateTime1, lesserDateTime));

If we don't do the comparison in this manner we are likely to get the above unexpected results. If you want to see the specifics of the Nullable.Compare method, read the MSDN Nullable.Compare documentation.

Old Blog Favorites

I am somewhat partial to a few of the posts from my previous blog. For some of these posts, I just like the post, some the content about which the post was written, and some were just popular posts.

Installing SQL Server Management Studio with SQL Server: My most popular post is one written about a painful experience installing SQL Server's client tools. Sadly the popular post is out of date. My first post about the topic I found a solution that worked and managed to install the software. I late found out that there was a better way and I updated the post. The problem is that Google continued to send traffic to the old one. For my blog it was a pretty popular post. it has had over 25,000 views.

The original version - Installing SQL Server Management Studio with SQL Server

The current version - SQL Server Client Tools Installation

Visible Whitespace in Visual Studio: Another post written about a traumatic experience was when I accidentally used a keyboard shortcut and enabled visible white space. It caused a blue dot to show for every space character in visual studio. Wow was it hard to read my code with that on. Well I Googled for it, and at the time I didn't receive any results. There are some now my post is one of them. I also didn't notice the option to turn it off. I used an algorithm I like to call brute force to figure out the keyboard shortcut I typed. It was Ctrl + E + S. Comments let me know of a bunch of other ways to solve the problem for different configurations and versions of Visual Studio.

Visible Whitespace in Visual Studio

Return Within a C# Using Statement: IDisposable objects are nice to work with. I prefer not dealing with external resources, which is generally what you're doing with disposable objects, but having this interface makes it a little bit nicer. I wrote a post telling people it was safe to return from within the using statement, because the using statement will make sure that the object is disposed. In the lifetime of the post only one person actually challenged me on it and asked me to provide code showing that what I said is true. I of course responded to that comment and then posted a response on this blog. My response includes sample code showing that using statements make sure that the object is disposed.

If you like the second post make sure you thank Lambros Kaliakatsos for commenting on the first one.

The original post - Return Within a C# using Statement

The follow up including sample code - Returning From Inside a Using Statement

Performance with DropDownLists and ViewState: One thing that it seems a lot of ASP.NET developers still don't understand very well is ViewState. Page lifecycle stuff seems to really be fueling the MVC craze these days. I wrote a post talking about how ViewState can hurt the performance of your applications if you let it get out of hand. The example I used is the drop down list, but it can certainly get a bit crazy from grids, repeaters, etc. I wrote an article basically saying that you should try to avoid ViewState if you're going to have too much of it. I later followed up with a post about how to use a DropDownList without ViewState. Some people are concerned that you will not be able to use the SelectedValue property, but you can if you wire it up correctly. It is all about understanding that painful Page Lifecycle.

Performance with DropDownLists and ViewState

Using a DropDownList without ViewState

There are plenty of other posts I like in there, but I think I've bored my readers enough for one day. I've got a couple of posts lined up which should be a little bit more interesting than this one, so keep reading. As always, have a great day.

One Reason to Test Before Creating a Method

Most people who know about Test Driven Development have heard the phrase, "Red, Green, Refactor". When it comes to actual implementation of this technique there seems to be a bit of a disagreement. By following the rules of RGR we all agree that we start by writing a failing test (Red), we write the code to make the test pass (Green), and then we make the code better and remove duplication (Refactor). The point of contention I hear about most often is in the Red stage. Some people say to write the failing test before writing any code. Some people say that you can make a skeleton of the code and write the test for that.

In practice I tend to agree with the people that make the skeleton code first. I really just don't like having the compiler error be how my test fails. What I do instead is create the code I am going to test and have it throw a NotImplementedException. This lets me make sure the test is failing so I am sure to flesh out the code.

Now I can certainly see reasons to do both. That is just what I prefer. One interesting problem which can arise from doing my method is the following. Say that I am going to create a new method on a class, so I create the method and write the failing test. Perhaps this is a non-tested project I am working on, so only the new stuff is tested. I write my code and everything passes now. But I've created a new bug. How?

I am kind of cheating here because there is a compiler warning. Since not everyone treats compiler warnings as errors it is certainly possible to have missed this problem. Here is some example code including an extra base class I didn't mention yet.

class Program
    static void Main(string[] args)
        Foo myFoo = new Foo();


internal class BaseFoo
    public void Bar()
        Console.WriteLine("Base Bar!!");

internal class Foo : BaseFoo
    public void Bar()

So now if I create a method called Bar without realizing there was already one on the parent class I will be hiding the parent one and breaking the existing logic. Since the old code isn't tested I will not know about it. If I had written a test before the code, I would have noticed something odd when the compiler didn't throw an error.

I think it is an interesting debate. Not very important, but interesting. Perhaps people have some more reasons why it should be one way or the other.

Dependency Injection for Testing - Car Analogy

One analogy I like using when talking about interfaces is the car. I like it because cars have a standard "interface" and most people know how to drive cars. In a post I wrote recently about dependency injection, I mentioned the importance of programming against interfaces instead of concrete classes.

For my car analogy I will start by saying that you are the program. You have been programmed against an interface. This is a good thing. You know how to drive a car. In this case "Car" is the interface. (Remember this means a literal interface, so it could be an abstract class.) You learned to drive a car. It doesn't matter what brand make or model. Since you know how to drive a car you can drive anything that implements the car interface even if it is not a car.

When you need to get from one place to another you can use any car with the same interface you know. This is very useful. You may not know how to operate all the features (methods) of that specific car. For example do you might not know how to operate the extra parts of a tow truck, but you could still drive it.

I like that analogy for interfaces.

How does testing fit this analogy?

Notice that I said earlier that, "you can drive anything that implements the car interface even if it is not a car". So before you can get your license to drive in the United States you need to pass a test. That is kind of like testing. Well there are two ways we could test your driving.

Right now the current system used to test drivers is an integration test. Perhaps in the future we will have a nice unit test to test our drivers. I am obviously going somewhere with this, so I will get straight to the point.

The way we test drivers now is we have someone sit in the car and watch what you do. We have to have very predictable courses set up in advance. We also have trouble controlling external variables (other drivers on the road). We can't control the weather for these tests, but they will be there when you're taking the test. Observations are made by an external entity (the person testing you) one that can't always get the exact interactions being made. All of these external resources even when they're controllable make this an integration test. We are dependent on too many other things.

A unit test for testing how well someone drives would need to break the dependency on a car by using an interface. We've done that. We are saying that a person knows the "car interface". Now we need some fake car that we can use for testing purposes to remove that piece we don't control. One that records all the interactions that the driver makes with the car, so we're not dependent on external observations of what is going on. We also need to break the dependency on real roads, since traffic conditions and the environment are difficult to change, control, and standardize. What does that sound like to me? A video game or in more professional terms; a simulator. The driver can sit down with this thing which has the same interface as a car, behaves as a car, works like a car. We can give the driver any scene, environment, conditions, etc. we want. We can also accurately measure all interactions with our fake car.

Maybe some day we will actually test drivers this way. It certainly would make it faster and easier to test. We could test more often. Considering that once someone has a license we don't test them again....

Would you do that with your code? I run unit tests every time I make a small change. Integration tests every time I check in.

Simple Dependency Injection

Dependency injection is an important concept for anyone to understand before trying to get into test driven development. Recently I've noticed that lots of people are trying to get into agile practices of software development. They're writing tests, and plenty of them are writing integration tests instead of unit tests.

Integration Tests Versus Unit Tests

When testing there are two main types of tests which are created. The ones most people write are integration tests, and this I attribute to their not knowing about dependency injection. If your code contains too many dependencies you will not be able to write unit tests.

Unit tests are the tests you need the most of usually. Unit tests should be testing the logic of your code. The core of your application should be your domain objects, your business logic, and well as the name states it should be the core code required for your application run. Unit tests should be fast. Because well-tested code will have hundreds of unit tests for even very small projects, it is important that unit tests run extremely quickly. This means that unit tests should never ever access external resources. This means your code in unit tests should never access a database or even use configuration files. Another reason to not access external resources is that they would need to be kept in a known state at all times for the test to work correctly.

Integration tests are also vitally important to a healthy and tested application. These tests serve a different role though. These tests aren't so much testing the pieces of your code like the unit tests are. The integration tests are here to make sure everything works together including the external resources. Integration tests do exactly as their name states, they make sure that everythign integrates well together.

Don't spend your time testing every case with integration tests. That is the responsibility of the unit tests. Unit tests are there to try to test all the different logical cases that your code handles. The unit tests should be examining a small portion of the code at a time. The integration test is there to make sure that each piece of the code is able to interact with each part with which it is supposed to interact. This allows you to make sure everything is linked together correctly. This means you should have some simple data accessing tests, mapping tests to verify that the properties of your classes mesh with the columns in your database tables.

Testing With dependencies

Using some very common methods of software development people don't build software in a very testable way. This means that we need to make some adjustments to how a lot of people have learned to structure their applications. Most code is able to be integration tested. Why? Integration tests are easier to do because our code is too tightly coupled together to test the individual pieces we would test using unit tests. Most software has so many dependencies in it that even simple unit tests are impossible, because they'll become integration tests if we start touching a database, a file, a web service, or anything else external to our code. If you're not testing one single tiny piece of code, then you're integration testing. Integration testing makes sure the dependencies are all working. Unit tests are testing only a unit of the code at a time. The problem is that once you test an object and its dependency you're also testing the dependency. This is why we want unit tests; so we can control what we are testing.

We need to break these dependencies before we can write our unit tests correctly. Once we've broken these dependencies we should be able to test the code.

Programming Against Interfaces

As a general rule, developers should program against an interface. Be as generic as possible. By interface I mean that in the normal sense not the programming one. Interfaces and abstract classes and anything similar are all acceptable. The point is that you're not programming using concrete classes. When the code executes it will run against concrete implementations of the interface, but most of the code should just use the interface. This allows us to substitute in implementations which are fake and allow us to manipulate their results.

Injecting the Dependency

In a previous post I wrote about how to begin unit testing, but I didn't explain the dependency injection very well. In that post I created an ICalendar interface. I programmed against this interface. Then in my tests I used a FakeCalendar class which implemented the interface, and I manipulated the values returned by that class so that I could test what I wanted to test. I have also created a concrete implementation of the ICalendar interface, and I use it as the default implementation. I used the simple dependency injection I refer to in this article.

I create two constructors for the class with the dependency; one that takes the dependencies and one that is the default constructor. The one with the extra parameters will be used by the test methods so that I can pass in the fake implementations, and the default one will be used by my production code. This lets me use different implementations between test and production code without having to muck up the production code.

This is an example of what a class might look like after the dependency has been removed. Pay attention to the two constructors and the fact that I am writing code against an interface and not a concrete class.

public class TimeOfDay
    private ICalendar _calendar;
    public TimeOfDay() : this(new Calendar())
    public TimeOfDay(ICalendar calendar)
        _calendar = calendar;
    public bool IsMorning()
        return (_calendar.GetCurrentTime().Hour < 10);
    public bool IsEvening()
        return (_calendar.GetCurrentTime().Hour >= 18);


Update: It seems that I failed. Steve Smith mentioned in a comment below that I forgot to mention what this pattern is called. This is the strategy design pattern. It follows the principle of programming to an interface instead of to a concrete class. The point of the pattern is that you select the algorithm (in our case a class) which you will be using at runtime. Testing is just one use of the strategy pattern. It is also very useful in general purpose coding.

Testing Private Methods

In a previous post about cutting large classes down in size I mentioned that

Sometimes there are methods kept private in a class. Some calculations are kept private because nothing should be calling those methods on this class. This is a good hint that the method belongs somewhere else. If the method is kept private because it doesn't make sense for a user of this class to use it, it belongs somewhere else.

Private methods are a common occurrence in classes. Sometimes they should be moved into another class, because they were only private because they didn't make sense in that class. Other times they are part of the internal workings of the class. At the end of the day it is always up to the developer how he is going to structure his code.

If you don't want to move the method and don't want to make it public you still have a couple of options to test it.

  • You can sometimes test a method through the public methods that call it. (Can be difficult sometimes because it is harder to control what is being passed to the method.)
  • You can write a public method which passes through to it, and prefix the name with "Test". (This is a bit hacky and should only ever be done with internal code that will not ever be in an API.)
  • You can change the method to protected and write a Test version of the class that inherits, and then exposes the method publicly on the test class. (This option works well because the test class can be kept with the tests so it doesn't dirty the production code. Only do this if you will not be subclassing this class already.)

Some people discourage testing private methods, because there really shouldn't be much logic in private methods that really needs to be tested. If it really needs tests it probably belongs in another class. My opinion is that if people are going to keep the code in the private method anyway, they might as well at least be testing it.

Structure your code how you like. Just don't let your classes get out of hand. If it becomes an issue then refactor it.

Friends don't let friends perform premature optimization.


As Donald Knuth said, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

I think it is safe to say this should apply to refactoring as well. Don't go on refactoring binges. Only refactor code you're currently working with.

The Most Important Refactorings

Testing and refactoring go hand in hand. When tests are in place we are safer to refactor because we have test in place which will help us preserve the previous functionality. When we are trying to add tests into code, we refactor the code to make it more testable. We refactor so we can test and we test so we can refactor. This may seem a bit cyclic, but both the refactoring and the tests improve our code. This makes it quite important to do them both anyway.

One problem which I've seen recurring in lots of different projects are classes and methods which are quite large. When classes and methods get long, they become difficult to test and maintain. It is easy to make mistakes when working with large classes or methods. In order to be able to work with and test large methods and classes we need to try to break them down into bite sized chunks that will be easy to handle.

The mistake people make when they do this is that they focus on testing the large method or class. We've already established that it isn't easy to test. Since it is not easy to test, we will test it last. How do we get the code where we can test it? We do exactly what I said in the first part of this post. We refactor the code so we can test it. Not the big piece. We pull out small pieces and test them.

We extract methods from our large method and test those pieces. We test them because they're small, bite sized, easy to test, pieces. Sure we don't get the whole method tested yet, but we can do it a piece at a time. As we extract these bits of code the method becomes much easier to read.

If there are now a few methods which have been extracted which seem to perform a similar responsibility we can extract them into a class with a name descriptive of that responsibility. The nice thing is that we now have a class which is easily testable and is tested since we tested each of its methods as we removed them from the large method in the other class.

Now if we're really feeling zealous we could extract an interface from the new class. As a general rule it is better to program against interfaces or abstract classes. The reason for this is that they are easy to test and easy to change when needed. We would then perform a task called dependency injection, which will allow us to use the concrete implementation in our production code and a fake object for our tests. This would then make testing the large method easier.

Even if you don't want to use the interface it is still easier to test the large method once it becomes a lot simpler and its individual pieces need less testing.