Skip to main content

Should test data be checked into version control? [Resolved]

I'm writing some test code for a feature which processes PDF files. The basic idea behind the tests is that I point them towards some PDFs I've selected specially, they process them and I check that the output is what I expect.

My question is: where should I be storing these large-ish PDFs? Should I check them into version control along with the code? Or put them somewhere else? Obviously, the test code is useless without the PDFs (or even with different PDFs) but still, putting them into our repository feels wrong.

Question Credit: Swiftheart
Question Reference
Asked September 13, 2018
Posted Under: Programming
5 Answers

If it's static data, then yes put it in version control. Those files won't really change once they're checked in; they'll either get removed if that functionality's no longer needed, or new test files will be added alongside. Either way, you don't need to worry about poor binary diffs taking up space.

If you're generating test data, eg. randomly, then you should automatically save it when a test fails, but discard it otherwise. Any data saved this way should be turned into regular regression tests, so that those edge-cases are definitely tested in the future rather than relying on the luck of the draw.

credit: Warbo
Answered September 13, 2018

Definitely include that data with your tests and your main application code. It helps to have a really well organised test suite - so if you're testing pdf extraction (and you have that code nicely encapsulated) then you should be able to construct a path to your test data, based on the path to the app code - that's always worked for me.

With git you can set up a .gitignore to prevent any temporary output or test logging from polluting your repo.

credit: NickJHoran
Answered September 13, 2018

There as a git extension called "git lfs", which stands for "Large File Storage". It is designed specifically to aid with synchronizing large binary files. See

After installing git lfs, the typical workflow is:

git lfs track "*.bin"
git add .gitattributes
git add file.bin
git commit -m "Add a binary file: file.bin"
git push

The first and second lines will cause files ending with '.bin' to be handled by git lfs instead of by git. *.bin files can then be added, committed, and pushed as in the 3rd, 4th, and 5th lines.

credit: Jasha
Answered September 13, 2018
Your Answer