File/Registry Test Case for NUnit

I am new (as of today) to NUnit and TDD. However, I am very interested in the technique and I am trying to learn. I have a test case I would like to read from a file if it exists, otherwise I will grab from the registry. How do I test both conditions? Here is an example of the code I would like to write a test case for:

    public static string ReferenceDirectory
    {
          get
        {
            string referenceDir = Path.Combine(_summitDataDirectory, REFERENCES_DIR); ;
            //If Windows Compliant data location does not exist, fall back on registry values
            if (!Directory.Exists(referenceDir))
                referenceDir = Path.Combine(GetRegi开发者_运维技巧stryValue("appPath"), @"Data\Databases\");                                    

            return referenceDir;
        }
    }

What I'm confused about is do I have to create two test cases: one in which I create the directory and another in which I remove the directory and read from registry? Also, at some point the registry will be cleaned and the value no longer will be in the registry which will mean this code is no longer valid unless I create the value in the registry.

To provide larger context, this code is for migrating our app to Vista/Win7 and thus I need to support the legacy path to the registry until all users are migrated.

Note: specific test code examples would be helpful as I'm completely new to NUnit.

EDIT: Modified code example based on comments.

---

Your tests should isolate and NOT test the MS methods for the directory or the registry. You can assume that Microsoft has coded them correctly. The easy way most people get around this is to move the calls to methods that can be overridden by a shunted class in the test so something like:

protected virtual bool DirectoryExists(string path){
   return Directory.Exists(path);
}

then in your tests, rather than test the class your dealing with; test a shunted class that extends the class under test and then override with:

protected override bool DirectoryExists(string path){
       return true; // or false or set a instance variable that you can manipulate
    }

The point is the last thing you want is for your test to have to create files or registry entries. That gets messy and slow.

and yes, this all means your property probably can't be static anymore.

!Edit for question If you absolutely need to keep the class static you can do something like this:

public class Foo{
private IDirectoryAccessor dir;

public static Foo(){
   dir = new MicrosoftDirectoryAccessor();
}    

public static SetDirectoryAccessor(IDirectoryAccessor dir){
  set this.dir = dir;
}

public static string ReferenceDirectory
{
      get
    {
        string referenceDir = Path.Combine(_summitDataDirectory, REFERENCES_DIR); ;
        //If Windows Compliant data location does not exist, fall back on registry values
        if (!dir.Exists(referenceDir))
            referenceDir = Path.Combine(GetRegistryValue("appPath"), @"Data\Databases\");                                    

        return referenceDir;
    }
}

You can always put the setter for the access object in a tested subclass

---

If I was testing this code, then here is my list of scenarios.

• Test code when referenceDir does exist.
• Test code when referenceDir does not exist and registry value does exist.
• Test code when referenceDir does not exist and registry value does not exist.

I would want to know what is the code going to do in each scenario. So to answer you first part, I would say you need to write three separate unit tests.

As for the situation where the registry key might be cleaned, I don't know what to recommend - if the key's not there, what could you use as plan B?

EDIT: I just noticed that referenceDir is not set to a value in your code, is there some code missing from your example, since Directory.Exist(referenceDir) will always fail.