aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard M. Stallman2003-08-06 01:21:53 +0000
committerRichard M. Stallman2003-08-06 01:21:53 +0000
commit46c7a6f0879c3735b8edac990bf67b59b594f54a (patch)
treed49c60402957be6eb3c55caea04d00d864c53107
parentfe45b975b94bccc550eafc37b160bdd8695e8d46 (diff)
downloademacs-46c7a6f0879c3735b8edac990bf67b59b594f54a.tar.gz
emacs-46c7a6f0879c3735b8edac990bf67b59b594f54a.zip
(Test Coverage): New node.
-rw-r--r--lispref/debugging.texi37
1 files changed, 37 insertions, 0 deletions
diff --git a/lispref/debugging.texi b/lispref/debugging.texi
index f0bbc9207cb..4a4c5914470 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.
30* Debugger:: How the Emacs Lisp debugger is implemented. 30* Debugger:: How the Emacs Lisp debugger is implemented.
31* Edebug:: A source-level Emacs Lisp debugger. 31* Edebug:: A source-level Emacs Lisp debugger.
32* Syntax Errors:: How to find syntax errors. 32* Syntax Errors:: How to find syntax errors.
33* Test Coverage:: Ensuring you have tested all branches in your code.
33* Compilation Errors:: How to find errors that show up in byte compilation. 34* Compilation Errors:: How to find errors that show up in byte compilation.
34@end menu 35@end menu
35 36
@@ -738,6 +739,42 @@ the old indentation actually fits the intended nesting of parentheses,
738and you have put back those parentheses, @kbd{C-M-q} should not change 739and you have put back those parentheses, @kbd{C-M-q} should not change
739anything. 740anything.
740 741
742@node Test Coverage
743@section Test Coverage
744@cindex coverage testing
745
746@findex testcover-start
747@findex testcover-mark-all
748@findex testcover-next-mark
749 You can do coverage testing for a file of Lisp code by first using
750the command @kbd{M-x testcover-start @key{RET} @var{file} @key{RET}}
751to instrument it. Then test your code by calling it one or more
752times. Then use the command @kbd{M-x testcover-mark-all} to display
753``splotches'' on the code to show where coverage is insufficient. The
754command @kbd{M-x testcover-next-mark} will move point forward to the
755next spot that has a splotch.
756
757 Normally, a red splotch indicates the form was never completely
758evaluated; a brown splotch means it always evaluated to the same value
759(meaning there has been little testing of what is done with the
760result). However, the red splotch is skipped for forms that can't
761possibly complete their evaluation, such as @code{error}. The brown
762splotch is skipped for forms that are expected to always evaluate to
763the same value, such as @code{(setq x 14)}.
764
765 For difficult cases, you can add do-nothing macros to your code to
766give advice to the test coverage tool.
767
768@defmac 1value form
769Evaluate @var{form} and return its value, but inform coverage testing
770that @var{form}'s value should always be the same.
771@end defmac
772
773@defmac noreturn form
774Evaluate @var{form}, informing coverage testing that @var{form} should
775never return. If it ever does return, you get a run-time error.
776@end defmac
777
741@node Compilation Errors 778@node Compilation Errors
742@section Debugging Problems in Compilation 779@section Debugging Problems in Compilation
743 780