also I feel like I'm re-inventing a wheel, but for some reason the question of exactly how you graft a testing regime onto a codebase that didn't previously have one doesn't seem to come up a whole lot these days

... or at least something you would **expect** to come up way more often with 30-year-old codebases that predate the "write your tests while you're writing your code" paradigm that seems to be prevailing now

Although I am perhaps also being weird in insisting that the test repository remain separate from the source repository because, oddly enough, I want to be able to switch between source commits/branches/versions without having my tests changing out from under me ...

1/n

#LambdaMOO

(in order to, say, know that a particular commit actually fixed something, or that a particular problem indeed existed in an old version) ...

....cannot imagine how devs would consider that acceptable and yet that seems to be the typical way of organizing codebases these days (i.e. one repo with everything + test subdirectory in the source; and frameworks I've looked at seem to assume this)

There's also the small matter that many of the tests may well be applicable to the various MOO forks out there, say if you want tests for language definition compliance or database file format correctness

(yeah I know, heaven forbid I should do anything that might benefit my competition; I evidently suck at capitalism; oh well...)

#LambdaMOO

2/2