Re: [rfc] plans for linespec.c

[Joel Brobecker <brobecker at gnat dot com>]

> There's actually an interesting question here as to whether or not I
> even can design coverage tests for the original version of
> decode_line_1: my only understanding of the function comes from
> decomposing it, so any tests that I'd design would be compromised by
> the assumption that I've preserved the behavior by that
> decomposition.  Though, obviously, I'd be in a good position for
> designing coverage tests for the newer version.

In my very modest experience - former engineer for the Canadian Automated
Air Traffic System (CAATS) project -, this is not a problem. If you can
create a set of tests that provide a good coverage of your code, then
your tests will be very helpful later on in any case because they will
allow you to verify that a modification does not introduce any change
in behavior. Any change can then be investigated.

Even if one of your test is wrong because there was a bug in the code
that twisted your understanding of what the function should do, the test
will one day "regress" when you fix the bug in the code. That day, the
regression will be investigated and the test will be corrected.
Eventually, you'll get close to 100% correct base of tests...

Most of the time on CAATS, the author of a given piece of code was also
given the task of doing the "unit testing", which includes writing
enough test drivers to exercice as much code as possible. These unit
test drivers proved to be invaluable. Hard to maintain sometimes (the
software quality was not always the same as in the CAATS code itself,
sigh), but very very very valuable, even today now that the project
has been delivered. Especially today I'd like to say, for the CAATS team
has lost a lot of its talents.

-- 
Joel