Closed oalders closed 4 years ago
See t/integration, there are several integration tests that do actually run yath to verify this kind of thing.
I did poke around there, but those aren't running the script itself, as far as I could tell. Also, that's running yath
inside of yath
which was an extra layer that I was trying to avoid. This way allows for setting @ARGV
without overriding it somewhere. This is a simple test case that demonstrates what the runner does without being run inside of a runner.
Having said that, if you don't like this, is there a specific test you can point out to me which I should follow as a pattern?
https://github.com/Test-More/Test2-Harness/blob/master/t/integration/test.t is a pretty simple one You also need to look at https://github.com/Test-More/Test2-Harness/tree/master/t/integration/test which contains the .tx files it runs. These integration tests do run yath inside of yath to get things correct.
Thanks for your help @exodist. This is ready for another review.
I messed around with trying to do this in the test scripts, but after a while I came to the conclusion that I really do want an integration test that really is testing how yath behaves at the command line. I wanted to do this in the most realistic way possible, so I've gone this route. It will obviously only fire under GitHub CI as it stands, but that may be enough to catch any future regressions.