Arguments for testing

[basxto]

Here what I propose for testing purposes:

• -quitonend (completely close warshmash after jass EndGame and return 0)
• -timeout X (autoquit X seconds after map is done loading and return ≠0, maybe 1?; or -autoquit)
• on error/crash also return ≠0, maybe 125?

It has to be possible to distinguish test failed (timeout) and evaluation not possible when the game crashes.
Bisect expects 0 for good, ≠0 for bad and 125 if the code can’t be tested, though it sounds like the latter is more for compile issues etc.
With a script this could be used for automatically finding a commit that broke a functionality with git bisect run <cmd> [<arg>...], which does a binary search and runs the test.
At least the initial version should be lightweight to patch it into old code with a .patch affecting portions of the code that don’t get changed a lot.

For the patches I’m rusty … that should’ve been git diff and git apply. Those don’t create new commits, which git format-patch and git am would do.

Diff has:

       -U<n>, --unified=<n>
           Generate diffs with <n> lines of context instead of the usual three. Implies --patch.

       --minimal
           Spend extra time to make sure the smallest possible diff is produced.

man git bisect has this example for merging from a special branch, but that would probably require that it is built on the oldest commit to test:

       •   Automatically bisect with temporary modifications (hot-fix):

               $ cat ~/test.sh
               #!/bin/sh

               # tweak the working tree by merging the hot-fix branch
               # and then attempt a build
               if      git merge --no-commit --no-ff hot-fix &&
                       make
               then
                       # run project specific test and report its status
                       ~/check_test_case.sh
                       status=$?
               else
                       # tell the caller this is untestable
                       status=125
               fi

               # undo the tweak to allow clean flipping to the next commit
               git reset --hard

               # return control
               exit $status

This indeed can only test if a map runs through to EndGame without any user interaction. Otherwise it would also need an option to input timed fake user inputs.

Edit: How well are replays already supported? I can’t really test that since I can’t create them with wsh. That is probably sufficient to use as user input for replays instead of inventing something new.