I've been developing a package which programatically generates music. The logic is non-trivial, data structures sometimes unwieldy and I'm used to the comfort of codebases secured by massive test coverage, which led me to a search for methods of automated testing in the LilyPond ecosystem.
The package's core functionality is pure Scheme code, not touching LilyPond APIs or data types, and thus easily unit-testable in complete isolation with the help of any unit-testing tool. I sticked to the basic SRFI 64 implementation included in Guile. (In the root directory of https://github.com/igneus/lilygabc the "make test" command runs these unit tests.) Testing the code which requires LilyPond runtime is trickier. I ended up dumping the music structures generated by my package with \displayMusic and \displayLilyMusic and comparing them with similarly dumped data structures of hand-coded examples. ("./test.sh" in the "tests/lily_structures" subdirectory of the same repo. Options --lily-only and --scheme-only allow executing only a subset of the checks.) There are some issues I haven't found a satisfactory solution for yet - particularly issues of music property order, which seems to be either non-deterministic, or following some non-obvious rules - but in general it seems to be a viable testing strategy. Am I reinventing the wheel? How do you all approach automated tests of your Scheme-heavy LilyPond packages? Regards, Jakub
