From your question:
We want to be able to keep a record of these test results, so we can go back and run the same test again with the same Inputs and verify the results – @user3711455
From your comment:
The .CSV changes daily. The test script's input is the output of a legacy system. It takes that, gets equivalent data from New system, and then compares to see if they both match. Resulting with a CSV that has: Legacy System Results, New System Results Total Differences: – @user3711455
These are not the same test. Running the same test, with the same inputs, against the same code should be a redundant exercise. If that doesn't always produce the same result you've allowed magic into your system.
This is useful only in verifying nothing magical is happening. More typically you rerun these tests making sure only one thing has changed. Usually refactored code. That way when the test breaks you know what to blame, the one thing that changed.
Running two systems side by side duplicating work for comparison is not a test. It's a voting system. When they disagree you have to decide who to believe. The legacy system shouldn't be trusted to be perfect no mater how many years it has under it's belt. In fact the older it is the more likely some mistakes it makes are so well known that everyone just ignores them since they are expected and may have never told you new guys about them since everyone knows that. You may get some value out of this proving the new system is ready to transition to operational but these are not tests since they require the old system to exist.
However, feed input to the old system and record the output and you have a baseline output. But just for that input, and just for that version of the legacy system. Which hopefully isn't buggy itself. From that you can build a test the new system. But if your inputs don't exercise every use case and every bit of code then you're just hoping to get lucky.
If, as I suspect, your
custom written test cases that cause the test cases to
change daily is just having both systems work from the same feed of operational input I don't have a lot of confidence that you have good code coverage.
If, however, you're input is hand tuned to exercise different parts of your code then those inputs and the code that automates testing them and comparing their outputs should be organized in a structurally similar manner to the code that they test so that it's very easy to navigate from one to the other. Do that and keep it all version controlled and you'll have a nice development system.