Flat File in a Unit Test

Question

Is it considered bad practice to use a flat file when doing unit tests? If an application reads in flat files and parses them, would this be a better approach than hard coding strings into the unit tests themselves?

Answer 1

It's only bad practice for sure if the text files aren't checked into version control.

There isn't anything hugely wrong with reading text files, provided the text files are in source control along side the class reading it.

However, I personally would rather hard code all the values into a bunch of lists because they are being used for unit tests. There is nothing wrong with that. Where I work I work on software that analyzes data from real world sensors. I have written python scripts that will take the flat text files and convert those into C# static class files ready for being plugged into the unit tests.

Answer 2

Does the flat file contain information that can be rendered in a human-readable form? If so, store the information in the most-human-readable format.

e.g. Script file, Text-based data representation, etc. Those can be placed together with the unit test code and checked into version control.

e.g. Image files, Audio files. The natural way to render an image file is to leave it as an image file, so that it can be opened by any image viewer. Don't try to store test image files in a format that makes them non-renderable (e.g. save it as Base64 in an XML file; unless you're testing a library that performs that conversion and you have an image viewer that can render the image for you)

e.g. synthetic binary data. In this case, it is better to write a test helper function that generates the synthetic binary data on the fly. The test helper function is the "human-readable form" that explains how the data is generated; nobody can understand that by looking at the data alone.

Answer 3

I personnally think it depends on what you are testing. I tend to try and break down my unit tests as small as possible and to only test one piece of functionality.

It seems to me you are trying to test two things here: 1. Reading in a file 2. Parsing that file

I might break down the unit tests to accomodate both those cases and in the case of 2. then I would consider hard coding strings a valid situation.

Answer 4

It doesn't matter much. If the test language supports multi-line string literals then it may be a bit easier and faster to include the data in the test code. If the test language has poor support for multi-line string literals (e.g. Java) then it will be easier to use a flat file.

Answer 5

There is nothing wrong with hard-coding values (whether they're strings, numbers, objects, etc.). The unit test is a strict test that determines the behaviour of a single type of input. Having all the information in the unit test itself provides an unchangeable value and is clearer to see what is being tested.

Answer 6

The advantage of flat files is that you can put many data there to feed the tests. The Django unit test framework works with fixtures, files with data for that purpose (in this case it use json or xml).

Another advantage is that your test code is written for taking the data from that file and is ready for testing synthetic data generated by hand (by now) or by machine, so you could then drop that file, save the script that generate the fixture and you don't have to change your test.