Yeah, although it’s not a builtin part of TADS3, just how I write things. I generally:
- Break any non-trivial new functionality into a standalone(-ish) module
- Write unit tests for all of the API methods/functions provided by the module to upstream modules/games
- Also write unit tests for upstream modules that depend on other modules but export them as a wrapped dependency. For example I have a module that provides instanceable PRNGs and a module for NPC decision-making that relies on it. The PRNG module has tests for the various pick-a-number methods it provides but I also wrote checks for the NPC module’s have-the-NPC-pick-an-option method…even though under the hood the latter is mostly just a wrapper around the former
- Independent of this kind of thing I wrote a module for implementing generic linters and I’ll write linter checks for new modules, particularly if there are a lot of gotchas. For example on the Markov chain module I put up the other day I added a linter check that looks for places where decimal probabilities are used and makes sure that all the options sum up to 1.0.
- And independent of all that, when I’ve got a case where there are a bunch of dependencies I usually use a module I wrote for doing full-on regression testing—using a reference game world and set of actions and comparing the transcript for different builds
I guess I also tend to write little one-off interactive debuggers for bigger/more complicated modules (like the transcript re-writing one). Those have sometimes ended up in the public version of the module (like in transcript re-writing module) but I frequently write an interactive debugger during development and then remove it before making the repo public (mostly so I don’t have to re-write the debugger to use less profanity).