Unit tests are mandatory for any business logic. But what if your business logic is parsing and processing files? Then you will need files as input in your tests.<\/p>\n
At first, I thought about making an extra wrapper around reading the file and mocking the wrapper when parsing it. However, sometimes this is more complicated than necessary. Plus, using actual files has more benefits. For example, if in Production you have a file that gives unexpected results, you can use that exact file in a new unit test, and then fix\/change the behavior using Test Driven Development. Or when you use a third-party tool to read the data, and mocking that third-party tool is not feasible.<\/p>\n
So, here is a simple example. Say we process our files with the following code:<\/p>\n\n
\nusing System;\nusing System.IO;\n\nnamespace ProcessFile\n{\n public class ProcessFile\n {\n \tpublic ProcessResult Process(string fileName)\n \t{\n\t\t\tif (!File.Exists(fileName)) \n\t\t\t\tthrow new ArgumentException($"File {fileName} does not exist", nameof(fileName));\n\t\t\t\/\/ Process file here...\n \t\treturn new ProcessResult(); \n \t}\n\n \tpublic ProcessResult Process(Stream fileStream)\n \t{\n\t\t\tif (!fileStream.CanRead)\n\t\t\t\tthrow new ArgumentException("Stream cannot be read", nameof(fileStream));\n\t\t\t\/\/ Process stream here...\n \t\treturn new ProcessResult();\n \t}\n }\n}\n<\/pre><\/div>\n\n\nThere are two functions here that need to be covered: one function that takes a file location, and one function that takes a stream. Both very reasonable examples. The actual business logic is left out because it is not relevant for now. <\/p>\n\n\n\n
Physical file<\/h2>\n\n\n\n
The first test looks like this:<\/p>\n\n\n
\n[Test]\npublic void GivenFile_WhenProcess_ThenResult()\n{\n \/\/ Given\n var target = new ProcessFile.ProcessFile();\n var testLocation = Assembly.GetExecutingAssembly().Location;\n\n var fileLocation = Path.Combine(Path.GetDirectoryName(testLocation), "TestFiles\/TestFile.csv");\n \/\/ When\n var result = target.Process(fileLocation);\n\n \/\/ Then\n Assert.Pass();\n}\n<\/pre><\/div>\n\n\nThe actual file is added to the test project. Make sure to set the property CopyToOutputDirectory<\/code> to either Always<\/code> or PreserveNewest<\/code> in the Project file:<\/p>\n\n\n\n<ItemGroup>\n <None Include="TestFiles\/TestFile.csv" CopyToOutputDirectory="PreserveNewest" \/>\n<\/ItemGroup>\n<\/pre><\/div>\n\n\nThe line Assembly.GetExecutingAssembly().Location<\/code> will give the location of the test assembly dll, which is then used to get the full location to the file we want to test.<\/p>\n\n\n\nStream<\/h2>\n\n\n\n
The test for the stream looks like this:<\/p>\n\n\n
\n[Test]\npublic void GivenStream_WhenProcess_ThenResult()\n{\n \/\/ Given\n var target = new ProcessFile.ProcessFile();\n var assembly = Assembly.GetExecutingAssembly();\n var stream = assembly.GetManifestResourceStream("ProcessFileTests.TestFiles.TestFileEmbedded.csv");\n\n \/\/ When\n var result = target.Process(stream);\n\n \/\/ Then\n Assert.Pass();\n}\n<\/pre><\/div>\n\n\nAgain, the actual file is added to the project, but as an embedded resource. In the project file:<\/p>\n\n\n
\n<ItemGroup>\n <EmbeddedResource Include="TestFiles\/TestFileEmbedded.csv" CopyToOutputDirectory="None" \/>\n<\/ItemGroup>\n<\/pre><\/div>\n\n\nUsing the testing assembly again, we retrieve the resource using its identifier: ProcessFileTests.TestFiles.TestFileEmbedded.csv<\/code>. This identifier is created automatically when building: it uses the project namespace plus the relative path, where the directories are notated with a . instead of a \/<\/p>\n\n\n\nSummary<\/h2>\n\n\n\n
So, there you have it: two ways to use files as input for unit testing: one with physical files and one with streams. Files are enclosed in the test project and delivered directly to the code to test.<\/p>\n\n\n\n