Testing output files is always a difficult thing, same goes for testing downloading files from the web or output to the console.
One question you should ask yourself is: "How far can I test until I need the file?" Most of the logic can be tested by using some kind of replacement code, or simple text file generator.
Looking at your question you can generate multiple files, so I guess you already have some sort of separation between the code that provides the data and the code that is generating the file. So my answer will be based on the assumption that there is a kind of factory that generates the actual file.
A question you can ask yourself is: how complex is the factory, does it contains lots of extra logic or is only calling functions from another library that is creating the files for you?
If the factory does have lots of logic, is this the same for all kind of outputs or different for each output? When it is the same, you should think of refactoring it out of the factory, or add a format that is easy to test (like a plain text file).
When it only calls the a library, do you really have to test it automatically? aren't you going to test the library you are using?
So basically I would test as much as possible that doesn't require me to create a complex file. Plain text files, including html and json are relative easy to test because they are readable and comparable.
To test the binary outputs, I would probably generate a simple sample file to test against and write a test that uses the factory to generate the same file and test the file at byte level. Generated with the same parameters should generate the same file over and over again.