My New Years Resolution - Use more shims

When I need to unit test my code in isolation, I typically use Moq to mock the interfaces that aren't related to the methods I'm testing. Until today, that is. I wanted to test a little bit of functionality that depends on values coming back from the System.IO namespace in .NET 4.5. Specifically, if a file in a given folder was more than a certain number of days old, it would get deleted. How do you unit test that? Here is the code that needs to be tested.

public void Rotate()
{
    var searchPattern = "*." + BaseName;
    var files = Directory.GetFiles(Folder, searchPattern);
    foreach (var file in files)
    {
        if (File.GetCreationTime(file) < DateTime.Now.Add(-MaxLogAge))
        {
            File.Delete(file);
        }
    } }

In the past, I probably wouldn't have bothered testing it. After all, it's pretty straightforward. Today I was feeling extra cautious.

The first problem with testing this is that Directory.GetFiles() is going to return me an array of files matching my search pattern. Unless I create some files, it will return an empty array. Next, File.GetCreationTime() will return the actual DateTime value. The only saving grace is that MaxLogAge is a user-specified TimeSpan value. Finally, do I really want to be deleting files in my unit tests? I've done worse in my career.

In fact, the first thought I had was to create a file in my test folder, set the MaxLogAge value to something like TimeSpan.FromMilliseconds(1), and check that the file really gets deleted. It would probably work, but it seems very inelegant, and possibly ineffective on a really fast machine.

Searching online  yielded a lot of opinions and suggestions, most of them involving abstracting System.IO. The idea is to create an interface containing just the functions I need, and then inject that into my class being tested. The concrete implementation would simply be a thin layer of code wrapping System.IO. During tests, I would continue to use Moq to provide a fake version. I considered it for awhile, and then remembered about the Fakes available in Visual Studio.

I had read about the Microsoft Fakes Assemblies before, but never gave them much thought until now. If you don't know about them, open a C# unit test project and expand the references folder. Now right-click an assembly and look for a context menu item called Add Fakes Assembly. Selecting this item will create a special wrapper for you around that assembly. Basically, you can intercept and change what happens when other code calls into these assemblies. Yes, it's as dangerous as it sounds, but there are some safeguards built in.

The most important safeguard is that your changes vanish when the fake context is disposed. Microsoft recommends wrapping the context inside a using statement, guaranteeing that your changes won't last outside of your tests.

Using the Fakes assemblies, I was quickly able to re-implement three System.IO methods so that I could test my logic in total isolation. The way I did that was with the following three lines of code.

System.IO.Fakes.ShimDirectory.GetFilesStringString = (s, p) => new[] { "2014-01-01.myapp.log" };
System.IO.Fakes.ShimFile.GetCreationTimeString = s => DateTime.Now.AddDays(-rotator.MaxLogAge.TotalDays + 2);
System.IO.Fakes.ShimFile.DeleteString = s => isDeleted = true;

Notice the namespace and class names. System.IO.GetFiles (the overload that takes two strings) is named System.IO.Fakes.ShimDirectory.GetFilesStringString(). I simply pass in a lambda expression that returns what I want the built-in method to return, and it does it. That's really all there is to it. I changed the logic to those three methods and called my method. If I did it correctly, my code would try to delete the file, which would simply set a flag I could check later.

The entire test method is here.

[TestMethod]
public void RotateRemovesFilesOlderThanDefaultMaxAge()
{
    using (ShimsContext.Create())
    {
        // Arrange
        var isDeleted = false;
        var rotator = new LogRotator();
        System.IO.Fakes.ShimDirectory.GetFilesStringString = (s, p) => new[] { "2014-01-01.myapp.log" };
        System.IO.Fakes.ShimFile.GetCreationTimeString = s => DateTime.Now.AddDays(-rotator.MaxLogAge.TotalDays - 1);
        System.IO.Fakes.ShimFile.DeleteString = s => isDeleted = true;
 
        // Act
        rotator.Rotate();
 
        // Assert
        Assert.IsTrue(isDeleted);
    }
}

Notice that I create a ShimsContext inside of the using statement, and include the entirety of the test inside the block. This ensures that my changes vanish when the test ends, and prevents those changes from leaking into any other test code accidentally.

The one snag I ran into was matching the .NET method to the appropriate Fakes method. At first, I used GetFilesString instead of GetFilesStringString, and couldn't figure out why it wasn't returning my array. After I got past that hurdle, the rest was easy. So you need to be careful, and understand what method you're really modifying.

I know there are many people who think that shims are evil and should be avoided at all costs. I am not one of those people. Used properly for testing, they solve a very specific problem in a very simple way. That said, if I ever saw the Fakes namespace in production code, I would consider some very harsh and severe punishment for the developer who added it.

I hereby make a New Year's Resolution that I will continue to explore shims, along with the rest of the Microsoft Fakes system. This is a resolution I think I can keep.

Comments

Popular posts from this blog

How to copy your Frozen Free Fall progress to a new phone

Ionic vs. Bootstrap - for a Web App

How I Finally Got AdMob and Ionic Framework to Play Nice Together