Creating Integration Tests with Embedded Files<!-- --> | <!-- -->Patrick Desjardins Blog
Patrick Desjardins Blog
Patrick Desjardins picture from a conference

Creating Integration Tests with Embedded Files

Posted on: January 26, 2015

Unit Testing changes a lot by the enterprise your are working on and also the team. Often, Unit Testing and Integration Testing are done with the Unit Test framework and this is fine. Something that is more rare is to define the limit. Defining a different between the two are important for several reasons. First of all, unit tests target a single operation; a unit. Unit tests are fast, does not have dependencies and when they fail show without a doubt where the error is located. A second reason is that integration test may require some dependencies, even need to do query to database. A third reason is that we want to flag longer test by using a test's category or by simply having them in a different assembly. Mostly because we do not want to run integration test on every commit but only once a day. The reason : speed. If you have thousand of tests, it should be executed in less than few seconds. If you have files to open, database connections, etc, this can lead to several minutes and increase by a lot your building time.

This article concerns integration test. The case is that we want to do an integration test on a file. This file contains a lot of Html elements and instead of creating a unit test for a single element, we want to execute the integration code that handle a complete file. We could have used a string with a lot of Html markup but editing the Html becode harder. It is also less clear and crowd the unit test file with huge string.

One option is to use embedded resource for file and inside the test to use the assembly method GetManifestResourceStream. This is the option that we are going to talk in this article. The first step is to create a folder where all your files for test will be used. I suggest that you put this folder inside the test assembly. This is not mandatory but is less confusing. The test codes is near of the test contents. After, I suggest that you have one folder per test class. This also help for maintenance to be able to figure out fast where is the file. Finally, my suggestion is to have another folder for each test. The reason is the same: simplify to search of resource. You can than create a file to use. In my scenario, an input file and an output file. The input file is what the test use to test the method to be tested. The output is the file to use to compare with the method result. It is the expected result.

The next step is to use that embedded file. Since we are using the same assembly that the unit test is created, we can call the Assembly.GetCallingAssembly method.

1var assembly = Assembly.GetCallingAssembly(); var resourceName = assembly.GetName().Name + ".YourTestContentFolder.SubClassFolder.SubMethodFolder.Input.html";

The resource file is embedded which has created the resource identifier by using the assembly name with all the folder structure up to the file name. The separator used between folder are the dot. Once you have the resourceName, you need to use the GetManifestResourceStream method with a StreamReader.

1using (var stream = new StreamReader(assembly.GetManifestResourceStream(resourceName), Encoding.UTF8)) { //... }

This solution is great but keep in mind that nothing is better than real unit test. A lot of thing can be wrong by doing to much processing in a test. This increase the possibility of having error that does not have any relationship with the real purpose of the test.