10

So far I created the following interface:

  public interface IDirectoryInfoWrapper
  {
    public IFileInfoWrapper[] GetFiles(string searchPattern, SearchOption searchType);
    public IDirectoryInfoWrapper[] GetDirectories();
  }

I've been going through the code replacing DirectoryInfo with IDirectoryInfoWrapper. All was going well until I found this:

  // Check that the directory is valid
  DirectoryInfo directoryInfo = new DirectoryInfo( argPath );
  if ( directoryInfo.Exists == false )
  {
    throw new ArgumentException
        ("Invalid IFileFinder.FindFiles Directory Path: " + argPath);
  }

It makes no sense to put the constructor in the interface, so what should I do with this line of code:

DirectoryInfo directoryInfo = new DirectoryInfo( argPath );
O.O
  • 11,077
  • 18
  • 94
  • 182
  • 1
    interface, of course, goes wihtout a constructor, but its implementation with the constructor. – ie. Jun 22 '12 at 15:53

2 Answers2

9

I see two obvious choices:

  1. Replace DirectoryInfo with your own wrapper implementation there (not ideal)
  2. Create a factory that can make IDirectoryInfoWrapper instances. You could make a Create function with overloads for each constructor you wanted to use.

I'm assuming you are doing this with dependency-injection, which would mean now you just inject that factory into any class needing to create new directory info objects.

Also, you would want to modify the wrapper interface to expose that Exists property

Edit: if you're doing this to try to unit-test something (which seems likely) then you might try reading Misko Hevery. Every time you use the new operator in C#, you have a point where you cannot inject something at runtime. This makes it very difficult to test anything using new in any but the most trivial of cases. For anything that isn't a simple data object, I pretty much always use a factory.

Edit II:

You're delegating the construction to the factory, so that's where you use the DirectoryInfo real constructor:

class Factory : IFactory 
{
  IDirectoryInfoWrapper Create(string arg)
  {
    var dirInfo = new DirectoryInfo(arg);
    var wrapper = new DirectoryInfoWrapper(dirInfo);
    return wrapper;
  }
}
Paul Phillips
  • 6,093
  • 24
  • 34
  • You'd still be using the real `DirectoryInfo` object, just with one layer of indirection. If you're writing unit tests using this class (which I'm assuming) then now you have to actually create directories to test this. A unit-test interacting with the file system is a bad idea, all kinds of problems can come up because you don't really control the file system. – Paul Phillips Jun 22 '12 at 15:59
  • No, in your unit tests you would use a mock implementation of IDirectoryWrapper and if you use the factory as well then you'd use a mock of the IFactory which returns a mock of the IDirectoryWrapper. No file system involved. – Alexander Derck Apr 27 '22 at 13:58
1

The link gives example how to mock File class you need to do similar for DirectoryInfo How do you mock out the file system in C# for unit testing?

Community
  • 1
  • 1
HatSoft
  • 11,077
  • 3
  • 28
  • 43