> Puzzle implementations written in this framework are self-testing as far as I could make them > Textual game and move descriptions, for example, are generate

> Puzzle implementations written in this framework are self-testing as far as I could make them > Textual game and move descriptions, for example, are generated and parsed as part of the normal process of play. Therefore, if you can make moves in the game at all you can be reasonably confident that the mid-end serialisation interface will function correctly and you will be able to save your game. (By contrast, if I'd stuck with a single make_move() function performing the jobs of both interpret_move() and execute_move(), and had separate functions to encode and decode a game state in string form, then those functions would not be used during normal play; so they could have been completely broken, and you'd never know it until you tried to save the game – which would have meant you'd have to test game saving extensively and make sure to test every possible type of game state. As an added bonus, doing it the way I did leads to smaller save files.) Is there a general name for code like this that deliberately makes use of functions it doesn't necessarily need to so that bugs are noticed early? I haven't heard it called self-testing but I don't have a name of it. I've done this before when features/functions are added that I know are rarely going to get called and I want an early warning if they break later by making sure they're called during regular usage.