summaryrefslogtreecommitdiff
path: root/lispref/debugging.texi
diff options
context:
space:
mode:
authorRichard M. Stallman <rms@gnu.org>2003-08-06 01:21:53 +0000
committerRichard M. Stallman <rms@gnu.org>2003-08-06 01:21:53 +0000
commit46c7a6f0879c3735b8edac990bf67b59b594f54a (patch)
treed49c60402957be6eb3c55caea04d00d864c53107 /lispref/debugging.texi
parentfe45b975b94bccc550eafc37b160bdd8695e8d46 (diff)
(Test Coverage): New node.
Diffstat (limited to 'lispref/debugging.texi')
-rw-r--r--lispref/debugging.texi37
1 files changed, 37 insertions, 0 deletions
diff --git a/lispref/debugging.texi b/lispref/debugging.texi
index f0bbc9207c..4a4c591447 100644
--- a/lispref/debugging.texi
+++ b/lispref/debugging.texi
@@ -30,6 +30,7 @@ compiler, you need to know how to examine the compiler's input buffer.
* Debugger:: How the Emacs Lisp debugger is implemented.
* Edebug:: A source-level Emacs Lisp debugger.
* Syntax Errors:: How to find syntax errors.
+* Test Coverage:: Ensuring you have tested all branches in your code.
* Compilation Errors:: How to find errors that show up in byte compilation.
@end menu
@@ -738,6 +739,42 @@ the old indentation actually fits the intended nesting of parentheses,
and you have put back those parentheses, @kbd{C-M-q} should not change
anything.
+@node Test Coverage
+@section Test Coverage
+@cindex coverage testing
+
+@findex testcover-start
+@findex testcover-mark-all
+@findex testcover-next-mark
+ You can do coverage testing for a file of Lisp code by first using
+the command @kbd{M-x testcover-start @key{RET} @var{file} @key{RET}}
+to instrument it. Then test your code by calling it one or more
+times. Then use the command @kbd{M-x testcover-mark-all} to display
+``splotches'' on the code to show where coverage is insufficient. The
+command @kbd{M-x testcover-next-mark} will move point forward to the
+next spot that has a splotch.
+
+ Normally, a red splotch indicates the form was never completely
+evaluated; a brown splotch means it always evaluated to the same value
+(meaning there has been little testing of what is done with the
+result). However, the red splotch is skipped for forms that can't
+possibly complete their evaluation, such as @code{error}. The brown
+splotch is skipped for forms that are expected to always evaluate to
+the same value, such as @code{(setq x 14)}.
+
+ For difficult cases, you can add do-nothing macros to your code to
+give advice to the test coverage tool.
+
+@defmac 1value form
+Evaluate @var{form} and return its value, but inform coverage testing
+that @var{form}'s value should always be the same.
+@end defmac
+
+@defmac noreturn form
+Evaluate @var{form}, informing coverage testing that @var{form} should
+never return. If it ever does return, you get a run-time error.
+@end defmac
+
@node Compilation Errors
@section Debugging Problems in Compilation