diff options
| author | Richard M. Stallman | 2003-08-06 01:21:53 +0000 |
|---|---|---|
| committer | Richard M. Stallman | 2003-08-06 01:21:53 +0000 |
| commit | 46c7a6f0879c3735b8edac990bf67b59b594f54a (patch) | |
| tree | d49c60402957be6eb3c55caea04d00d864c53107 | |
| parent | fe45b975b94bccc550eafc37b160bdd8695e8d46 (diff) | |
| download | emacs-46c7a6f0879c3735b8edac990bf67b59b594f54a.tar.gz emacs-46c7a6f0879c3735b8edac990bf67b59b594f54a.zip | |
(Test Coverage): New node.
| -rw-r--r-- | lispref/debugging.texi | 37 |
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, | |||
| 738 | and you have put back those parentheses, @kbd{C-M-q} should not change | 739 | and you have put back those parentheses, @kbd{C-M-q} should not change |
| 739 | anything. | 740 | anything. |
| 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 | ||
| 750 | the command @kbd{M-x testcover-start @key{RET} @var{file} @key{RET}} | ||
| 751 | to instrument it. Then test your code by calling it one or more | ||
| 752 | times. Then use the command @kbd{M-x testcover-mark-all} to display | ||
| 753 | ``splotches'' on the code to show where coverage is insufficient. The | ||
| 754 | command @kbd{M-x testcover-next-mark} will move point forward to the | ||
| 755 | next spot that has a splotch. | ||
| 756 | |||
| 757 | Normally, a red splotch indicates the form was never completely | ||
| 758 | evaluated; a brown splotch means it always evaluated to the same value | ||
| 759 | (meaning there has been little testing of what is done with the | ||
| 760 | result). However, the red splotch is skipped for forms that can't | ||
| 761 | possibly complete their evaluation, such as @code{error}. The brown | ||
| 762 | splotch is skipped for forms that are expected to always evaluate to | ||
| 763 | the same value, such as @code{(setq x 14)}. | ||
| 764 | |||
| 765 | For difficult cases, you can add do-nothing macros to your code to | ||
| 766 | give advice to the test coverage tool. | ||
| 767 | |||
| 768 | @defmac 1value form | ||
| 769 | Evaluate @var{form} and return its value, but inform coverage testing | ||
| 770 | that @var{form}'s value should always be the same. | ||
| 771 | @end defmac | ||
| 772 | |||
| 773 | @defmac noreturn form | ||
| 774 | Evaluate @var{form}, informing coverage testing that @var{form} should | ||
| 775 | never 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 | ||