On Nov 1, 2016, at 03:55 , Chris Yate <chrisy...@gmail.com> wrote: > > It's probably pedantry, but "unit tests" by most good definitions ought not > to touch stuff like network, threads, filesystems and databases. If we're > testing the graphic output it's too high level.
Agreed. > Unit tests would directly examine the staff object after the function call > for correct note placement, and the return value in exceptional cases. Beware of implementing tests with a higher maintenance cost and low marginal benefit over the current systemic regression tests. (I think test maintenance effort is a bigger problem than test run time in this project. Others may disagree.) A category of unit tests that could be helpful fall into the “robustness” category: feed a component some input that could cause embarrassing results, which is more difficult to provide when the component is integrated into the production code. The things in the “flower” directory seem like good candidates for broader unit testing. They seem to change infrequently and they are less complex than the parsing and engraving components. — Dan _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
