summaryrefslogtreecommitdiff
path: root/subversion/tests/README
diff options
context:
space:
mode:
Diffstat (limited to 'subversion/tests/README')
-rw-r--r--subversion/tests/README43
1 files changed, 42 insertions, 1 deletions
diff --git a/subversion/tests/README b/subversion/tests/README
index 6ea4b81..9a506cd 100644
--- a/subversion/tests/README
+++ b/subversion/tests/README
@@ -20,7 +20,7 @@ sub-tests it can run. It has a standard interface:
1. If run with a numeric argument N, the program runs sub-test N.
-2. If run with the argument `list', it will list the names of all sub-tests.
+2. If run with the argument `--list', it will list the names of all sub-tests.
3. If run with no arguments, the program runs *all* sub-tests.
@@ -130,6 +130,47 @@ This same rule applies to Subversion development: ** If you fix a
bug, write a test for it. **
+When to file a related issue
+----------------------------
+
+By definition, if you write a new test which is set to XFail, then it
+assumed that the test is for a known bug. In these cases it is
+recommended that you associate an issue in the issue tracker with the
+XFailing test. This ensures that the issue tracker is the authoritative
+list of known bugs -- see http://subversion.tigris.org/issue-tracker.html.
+You may need to create a new issue if one doesn't already exist.
+
+For C tests simply add a comment noting any associated issue:
+
+ /* This is for issue #3234. */
+ static svn_error_t *
+ test_copy_crash(const svn_test_opts_t *opts,
+ apr_pool_t *pool)
+ {
+ apr_array_header_t *sources;
+ svn_opt_revision_t rev;
+ .
+ .
+
+For Python tests use the @Issue() decorator (a summary comment of the
+issue never hurts either):
+
+ #---------------------------------------------------------------------
+ # Test for issue #3657 'dav update report handler in skelta mode can
+ # cause spurious conflicts'.
+ @Issue(3657)
+ @XFail()
+ def dav_skelta_mode_causes_spurious_conflicts(sbox):
+ "dav skelta mode can cause spurious conflicts"
+ .
+ .
+
+Of course it isn't *always* necessary to create an associated issue.
+If a the fix for an new XFailing test is imminent, you are probably
+better off simply fixing the bug and moving on. Use common sense, but
+when in doubt associate a new issue.
+
+
What not to test
----------------