[Proj] Testing framework
mateusz at loskot.net
Tue May 29 14:14:15 EST 2018
On Tue, 29 May 2018, 20:37 Kristian Evers, <kreve at sdfe.dk> wrote:
> So in summation my proposed TODO list goes something like:
> 1. Move tests from src/ to the Catch2 framework
> 2. Move selftest remnants in gie.c to the Catch2 framework
> 3. Move shell-script tests in nad/ to test/
> 4. Add a test framework for the command line applications, also in
> Thoughts? What have I missed?
Although might be to early, but perhaps an outline of tests organization
into suites and cases.
- test suite per API function - a sort of unit kind of tests focused on
exercising single function (similar tests also could verify definitions of
data structures). Eg. Call foo(a, b) with valid, invalid, boundary, random,
etc. values for parameters.
- test suites of more complex test cases, more complex Arrangements
preparing for actual test as well as more elaborate assertions following a
testing act - I like to think of those as functional tests (function is a
black box) or inter-function integration tests :) Eg. Verifying conversion
of X from CRS A to B gives expected results, depending on input valid,
To me personally, names and definitions of particular testing do not really
matter as long as there is agreement, at test case level, about what
behaviour is actually being tested and asserted (sticking with single
assertion per test case is a good method to reveal smelly places where it
is hard to tell what is being tested)
Any suggestions on how to test the command line
- extract gist of program logic into utility libraries (technique used in
OSRMand GDAL too, AFAIR)
- run programs directly (either via OS-specific C/C++ API or Python or...)
and parse/check it's output.
Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj