I understand your question as "A good/accepted way to test a class that depends on file system operations". I donot assume that you want to test the filesystem of your os.

In order to keep the effort to 'interfaces to your filesystem operations and "mock them out"' as @Doc Brown answer suggested as small as possible it is a good idea to use java **binary streams** or **text reader** (or ther equivalent in c# or the programming language you are using) **instead of using Files with filenames** directly in you tdd-developed class.

Example:

Using java I have implemented a class CsvReader

	public class CsvReader {
		private Reader reader;

		public CsvReader(Reader reader) {
			this.reader = reader;
		}
	}
	
For testing I used in memory data like this

	String contentOfCsv = "TestColumn1;TestColumn2\n"+
		"value1;value2\n";

	CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));

or embend testdata into the resources

	CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));
	
In production I use the file system

	CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));

This way my CsvReader does not depend on filesystem but on an abstraction "Reader" where there is an implementation for filesystem.