As part of a separate effort to write a modular replacement for adv3’s
executeCommand() (in turn part of my effort to implement noun-as-verb actions in adv3), I’ve written a very rudimentary framework for bolting regression testing onto existing games. It is available from my regressionTest git repo.
The approach is slightly less black box than most regression tests, because I’m not interested in testing the interpreter, but rather changes made to the builtin parser by individual games/modules. So instead of implementing a purely “external” testing method, the gimmick here is that the module provides its own self-contained gameworld and player object, and runs all of its tests using them. So it is (in theory) easy to drop the module into an existing project with virtually no modifications.
I’m not sure how much use most authors would get out of such a thing, but I’m in the specific situation where I often want to do a/b testing to verify that some tinkering I’m doing with parser internals isn’t interacting with/breaking something I don’t realize I’m affecting (for example, I recently discovered my first pass at a modular
executeCommand() replacement broke
QuitAction uses a special exception inside of
yesOrNo(), and my bespoke parser loop was trying to handle the exception itself).
The basic workflow is something like:
- Build the demo game using the provided source and makefile
- Create a command file using
>RECORDwhile playing the demo via
frob(or presumably some other interpreters, but I’ve only tested with
frob). The command file should end with
>Yto that the test scripts automagically exit the interpreter during replay as well
- Copy the command file into the
- From the
./scriptsdirectory, run the
generate_transcript.shscript. This will re-build the game (insuring the right flags are set during compilation) and then run it with the supplied command file, saving the transcript to
Then you can include the module by adding
-lib [path to module]/regressionTest to an existing project.
Having done that, then from the top of the source tree of the game to be tested you can run the
regression_test.sh script, which will re-build the project, run the game with the command file, save the transcript, and then diff the test transcript and the reference transcript.
All of the “stuff” in the module is inside preprocessor flags, so you can enable or disable it all by toggling the
-D REGRESSION_TEST flag when compiling the project.
The scripts presume the layout of the project to be tested will follow the conventions I use in my T3 modules, but everything is controlled by variables at the top of the script so they should be easy to tweak if your projects use a different code layout. Optional command line arguments are also documented in the comments at the top of the scripts, and can be displayed by running the scripts with the
Feedback welcome. I’d particularly like to expand the scope of the toy gameworld used by the testing process, and to implement more “differentiating” test behaviors in the command file. That is, to identify more actions that exercise different parser bits to verify they’re working: so
>TAKE PEBBLE and
>TAKE ALL involve slightly different bits of parser code even if the game effects are identical;
>BOB, TAKE PEBBLE uses a bunch of different code that when the player does a
>TAKE PEBBLE, and so on.