Mercurial > hg > xemacs-beta

comparison man/internals/internals.texi @ 1183:c1553814932e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[xemacs-hg @ 2003-01-03 12:12:30 by stephent] various docs <873coa5unb.fsf@tleepslib.sk.tsukuba.ac.jp> <87r8bu4emz.fsf@tleepslib.sk.tsukuba.ac.jp>
author stephent
date Fri, 03 Jan 2003 12:12:40 +0000
parents 9eddcb9548e2
children 465bd3c7d932
comparison
equal deleted inserted replaced
1182:7d696106ffe9 1183:c1553814932e
3633 @code{Skip-Test-Unless} is intended for use with features that are normally 3633 @code{Skip-Test-Unless} is intended for use with features that are normally
3634 present in typical configurations. For truly optional features, or 3634 present in typical configurations. For truly optional features, or
3635 tests that apply to one of several alternative implementations (eg, to 3635 tests that apply to one of several alternative implementations (eg, to
3636 GTK widgets, but not Athena, Motif, MS Windows, or Carbon), simply 3636 GTK widgets, but not Athena, Motif, MS Windows, or Carbon), simply
3637 silently suppress the test if the feature is not available. 3637 silently suppress the test if the feature is not available.
3638
3639 Here are a few general hints for writing tests.
3640
3641 @enumerate
3642 @item
3643 Include related successful cases. Fixes often break something.
3644
3645 @item
3646 Use the Known-Bug-Expect-Failure macro to mark the cases you know
3647 are going to fail. We want to be able to distinguish between
3648 regressions and other unexpected failures, and cases that have
3649 been (partially) analyzed but not yet repaired.
3650
3651 @item
3652 Mark the bug with the date of report. An ``Unfixed since yyyy-mm-dd''
3653 gloss for Known-Bug-Expect-Failure is planned to further increase
3654 developer embarrassment (== incentive to fix the bug), but until then at
3655 least put a comment about the date so we can easily see when it was
3656 first reported.
3657
3658 @item
3659 It's a matter of your judgement, but you should often use generic tests
3660 (@emph{e.g.}, @code{eq}) instead of more specific tests (@code{=} for
3661 numbers) even though you know that arguments ``should'' be of correct
3662 type. That is, if the functions used can return generic objects
3663 (typically @code{nil}), as well as some more specific type that will be
3664 returned on success. We don't want failures of those assertions
3665 reported as ``other failures'' (a wrong-type-arg signal, rather than a
3666 null return), we want them reported as ``assertion failures.''
3667
3668 One example is a test that tests @code{(= (string-match this that) 0)},
3669 expecting a successful match. Now suppose @code{string-match} is broken
3670 such that the match fails. Then it will return @code{nil}, and @code{=}
3671 will signal ``wrong-type-argument, number-char-or-marker-p, nil'',
3672 generating an ``other failure'' in the report. But this should be
3673 reported as an assertion failure (the test failed in a foreseeable way),
3674 rather than something else (we don't know what happened because XEmacs
3675 is broken in a way that we weren't trying to test!)
3676 @end enumerate
3638 3677
3639 3678
3640 @node CVS Techniques, A Summary of the Various XEmacs Modules, Regression Testing XEmacs, Top 3679 @node CVS Techniques, A Summary of the Various XEmacs Modules, Regression Testing XEmacs, Top
3641 @chapter CVS Techniques 3680 @chapter CVS Techniques
3642 @cindex CVS techniques 3681 @cindex CVS techniques