For #1,

It also means that the test data is separate from the container.t file, so it would be easy for the two to get out of sync.

Your data in a test file should not become out of sync if you are properly managing your tests. The tests are there to point out your short-comings and that would include problems with your test data.

For #2, if you cannot keep your data straight in a seperate test file why should generating an input file should be superior? You can make mistakes with the test file that you generate and add another area you have to debug.

For #3, I would only use the Mock tests when you have to replicate an environment that needs a special setup and will not run any other way. An example, a module that you have to run with mod_perl on Apache. When you are running your tests during the build process it obivious you don't have mod_perl so the Test::Mock* would be good here.

for #4, I would not extend code in my modules to support testing. Debugging, yes, testing, no. It means that you have not thought enough about how to setup your tests.

For #5, like #4 you are changing your code to support testing and would advise against it.

---

If you are going to run a comprehensive test suite with randomly generated data, I would suggest generating a test file, otherwise stick with a static pregenerated test file.