Re: Unit testing

[Dan Eble]

On Nov 1, 2016, at 03:55 , Chris Yate <address@hidden> 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