TDD: Is it plausible to have integration tests, but no unit tests?

Question

Technology Stack: .NET 4, C#, NUnit

I am attempting to apply test driven development to a new project that performs image processing. I have a base class that contains shared file I/O methods and subclasses that perform various specific processing algorithms. As I understand it, unit tests do not touch the file system or other objects, and mock behavior where that occurs. My base class only contains simple accessors and straightforward file system I/O calls.

public class BaseFile
{
    public String Path { get; set; }

    public BaseFile()
    {
        Path = String.Empty;
    }

    public BaseFile(String path)
    {
        if (!File.Exists(path))
        {
            throw new FileNotFoundException("File not found.", path);
        }

        Path = path;
    }
}

Is there any value in testing these methods? If so, how could I abstract away the calls to the file system?

My other question is how to test the subclass which is specific to a type of image file (~200 MB). I have searched the site and found similar questions, but none dealing with the file sizes I am working with on this project. Is it plausible for a class to have integration tests (using a "golden file"), but no unit tests? How could I strictly follow TDD methods and first write a failing test in this case?

Answer 1

In answer to your first question, yes there is value in testing these methods. I have published a library that facilitates doing exactly that without actually hitting the file system: https://bitbucket.org/mylesmcdonnell/mpm.io/wiki/Home

In (not an) answer to your second question I would need to see some code, but I suspect you may need to take a similar approach to the above lib. namely; define interface, define proxy to concrete, define factory to return proxy or mock.