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?

6 Answers 6


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.

  • 1
    At some point I give up and start using real files. But not until I really have to, it's normally possible to do 99% of it using hard-coded data. I think I have two file-based tests. Both are regression tests and I'm testing something like "after 65k iterations something bad happens" or "files larger than 2GB do not work" (what, someone reintroduced the small file size bug? Say it isn't so).
    – Мסž
    Commented Jun 16, 2011 at 3:55
  • +1 for the headline. A flat file is nothing but test data, absolutely acceptable if it is version controlled along with the tests. We just have to make sure that a test is repeatable. Commented Jun 16, 2011 at 7:12

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.


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.

  • I think it's OK to test 2 things if you've tested the first (reading a file) thing before hand.
    – Ross
    Commented Jun 16, 2011 at 0:36

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.


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.

  • 1
    I tend to agree. While I wouldn't see a flat file being used in a unit test as terrible, it's a ways from "good" too. At the least, it's another external dependency to manage. Commented Jun 16, 2011 at 0:02
  • Interesting. So perhaps it'll be better to have my values into a separate class in the unit test project or something similar?
    – Jon
    Commented Jun 16, 2011 at 0:13

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.