Unit Testing File I/O

by

There isn’t necessarily one thing to do when testing the file system. In truth, there are several things you might do, depending on the circumstances.

The question you need to ask is: What am I testing?

  • That the file system works? You probably don’t need to test that unless you’re using an operating system which you’re extremely unfamiliar with. So if you’re simply giving a command to save files, for instance, it’s a waste of time to write a test to make sure they really save.

  • That the files get saved to the right place? Well, how do you know what the right place is? Presumably you have code that combines a path with a file name. This is code you can test easily: Your input is two strings, and your output should be a string which is a valid file location constructed using those two strings.

  • That you get the right set of files from a directory? You’ll probably have to write a test for your file-getter class that really tests the file system. But you should use a test directory with files in it that won’t change. You should also put this test in an integration test project, because this is not a true unit test, because it depends on the file system.

  • But, I need to do something with the files I get. For that test, you should use a fake for your file-getter class. Your fake should return a hard-coded list of files. If you use a real file-getter and a real file-processor, you won’t know which one causes a test failure. So your file-processor class, in testing, should make use of a fake file-getter class. Your file-processor class should take the file-getter interface. In real code, you’ll pass in the real file-getter. In test code you’ll pass a fake file-getter that returns a known, static list.

The fundamental principles are:

  • Use a fake file system, hidden behind an interface, when you’re not testing the file system itself.
  • If you need to test real file operations, then
    • mark the test as an integration test, not a unit test.
    • have a designated test directory, set of files, etc. that will always be there in an unchanged state, so your file-oriented integration tests can pass consistently.

More Related Contents:

  1. How can we run a test method with multiple parameters in MSTest?
  2. Compare equality between two objects in NUnit
  3. NUnit vs. Visual Studio 2008’s test projects for unit testing [closed]
  4. Unit testing and checking private variable value
  5. MSTest Equivalent for NUnit’s Parameterized Tests?
  6. C# – Asserting two objects are equal in unit tests
  7. How do you test private methods with NUnit?
  8. Dependency injection with a static logger, static helper class
  9. How do I test database-related code with NUnit?
  10. How do I run NUnit in debug mode from Visual Studio?
  11. Unit test for thread safe-ness?
  12. Using DI container in unit tests
  13. Is it a good way of unit testing to use another, tested function to make preparations for the actual test?
  14. One DbContext per web request… why?
  15. Dependency Inject (DI) “friendly” library
  16. How do I generate a stream from a string?
  17. Resolving instances with ASP.NET Core DI from within ConfigureServices
  18. Creating application shortcut in a directory
  19. Unit Testing: DateTime.Now
  20. ASP.NET Core Dependency Injection error: Unable to resolve service for type while attempting to activate
  21. Mocking IPrincipal in ASP.NET Core
  22. Does MSTest have an equivalent to NUnit’s TestCase?
  23. Controlling execution order of unit tests in Visual Studio
  24. Dependency Injection – new instance required in several of a classes methods
  25. How to get the location of the DLL currently executing?
  26. Async provider in .NET Core DI
  27. Integration test and hosting ASP.NET Core 6.0 without Startup class
  28. Windows Phone 8: Media file access
  29. Write to a file from multiple threads asynchronously c#
  30. Mocking using Moq in c#

Leave a Comment