The intention here is to make it possible to wrap up many of the
KiCad utility tools into a single executable. This reduces link times
as well as the duplication of CMake files needed to build very
similar tools.
This particular tool should be suitable for any code in common,
code in pcbnew and other end-executables probalby will need an
analagous version linked to the relevant kiface.
The first tool is the coroutine_example.cpp test case, which
can be useful when learning, debugging or porting the coroutine
infrastructure.
This includes:
* Linkage against the Boost unit test libs
* Configuration of the Boost libs
* A place for common generics "extras" for unit test harnesses
including
* A simple way to allow "expected-failure" tests (without
breaking Boost < 1.58, e.g. Ubuntu LTS)
* Moving some simple numeric predicates from the geom tests
to the utils library.
Expand unit test docs to describe the expected failures macro.
Add a few COLOR4D tests, including one with expected failures due
to a pre-existing bug. This will be fixed in a follow-up commit.
This adds a test program which can be used to test the
parsing of a given KiCad PCB file. This interface is
useful for both manual or automated debugging of given
files, as well as providing an interface suitable for
fuzz-testing tools.
Also adds to the testing docs to detail how fuzzing can
be used.
Also moves some useful re-usable code from io-benchmark
to a new library qa_utils, which can contain code that
isn't need in the actual KiCad libs.
* Renames /qa/common to /qa/qa_utils, as it is not to do with /common
* Renames /qa/geometry to /qa/common
* Put existing geometry tests into a subdirectory of /qa/common, to
echo the layout of the main tree.
The intention is to provide a place to put tests of other libcommon
code in the /qa/common suite.
This is the first test for a generic test suite for geometric functions.
The tests run are for fillet corners of SHAPE_POLY_SETS.
Previously, SHAPE_POLY_SET::Fillet was tested against CPolyLine::Fillet
to ensure compatibility. However, thse two functions now have different
interfaces and are not directly comparable. Also, this depended on
CPolyLine::Fillet being correct, which was not tested.
Instead, test SHAPE_POLY_SET::Fillet using tests against geometric
constraints, independent of any other fillet implementation.
This test is not really concerned with generic geometric code testing,
but rather the correctness of a refactoring effort.
Rename it make this clearer, and also to make way for generic geometry tests.
Adds BOOST tests to the qa folder included in the geometry subdirectory.
The tests check whether the refactored code is consistent with the
legacy code. They also check some of the new code, as the family of
ITERATOR classes.