One test has pads of a bunch of different shapes and provokes some
errors to make sure they're caught.
The others are all past issues with the zone filler to make sure we
don't suffer any regressions. (They should all just pass with no DRC
errors.)
Several pcbnew_tools utilities read a file from the command line.
Instead of replicating this code, centralise the code in
qa_pcbnew_utils, which allows simpler reuse.
THe utilities are:
* polygon_triangulation
* polygon_generator
* drc_tool
pcb_parser keeps its own function, as that is the focus of the tool,
and its likely to have its own instrumention.
This also adds the ability to read from stdin for the above tools,
which means fuzz testers could theoretically work with them, and it
also can make life easier if you can pipe a board to the executable
directly.
Introduce the concept of a DRC_PROVIDER which allows
to separate the various DRC functions to their own
areas. This allows, amongst other things, a slimmer core
DRC class, and allows DRC functions to be separately testable.
The courtyard DRCs (overlap, missing and malformed)
are the first victims, so instrumentation can be added to this function.
Add some unit tests on this DRC function, as well a few re-usable PCB-based
utility functions in a library (qa_pcbnew_utils) that could be shared between
unit tests and other utilities.
Jeff Young
John Beard