Homepage: https://www.gnu.org/software/emacs
Author: Jonathan Yavner
Visual code-coverage tool
* Use `testcover-start' to instrument a Lisp file for coverage testing.
* Use `testcover-mark-all' to add overlay "splotches" to the Lisp file's
buffer to show where coverage is lacking. Normally, a red splotch
indicates the form was never evaluated; a brown splotch means it always
evaluated to the same value.
* Use `testcover-next-mark' (bind it to a key!) to jump to the next spot
that has a splotch.
* Basic algorithm: use `edebug' to mark up the function text with
instrumentation callbacks, walk the instrumented code looking for
forms which don't return or always return the same value, then use
Edebug's before and after hooks to replace its code coverage with ours.
* To show good coverage, we want to see two values for every form, except
functions that always return the same value and `defconst' variables
need show only one value for good coverage. To avoid the brown
splotch, the definitions for constants and 1-valued functions must
precede the references.
* Use the macro `1value' in your Lisp code to mark spots where the local
code environment causes a function or variable to always have the same
value, but the function or variable is not intrinsically 1-valued.
* Use the macro `noreturn' in your Lisp code to mark function calls that
never return, because of the local code environment, even though the
function being called is capable of returning in other cases.
Problems:
* `equal', which is used to compare the results of repeatedly executing
a form, has a couple of shortcomings. It considers strings to be the same
if they only differ in properties, and it raises an error when asked to
compare circular lists.
* Because we have only a "1value" class and no "always nil" class, we have
to treat as potentially 1-valued any `and' whose last term is 1-valued,
in case the last term is always nil. Example:
(and (< (point) 1000) (forward-char 10))
This form always returns nil. Similarly, `or', `if', and `cond' are
treated as potentially 1-valued if all clauses are, in case those
values are always nil. Unlike truly 1-valued functions, it is not an
error if these "potentially" 1-valued forms actually return differing
values.