diff -r 7997c0e01bfc -r d0bbd8ee50c7 tests/README --- a/tests/README Tue Dec 19 16:37:45 2006 -0600 +++ b/tests/README Tue Dec 19 16:38:14 2006 -0600 @@ -1,93 +1,7 @@ -A simple testing framework - To run the tests, do: cd tests/ python run-tests.py -This finds all scripts in the test directory named test-* and executes -them. The scripts can be either shell scripts or Python. Each test is -run in a temporary directory that is removed when the test is complete. - -A test- succeeds if the script returns success and its output -matches test-.out. If the new output doesn't match, it is stored in -test-.err. - -There are some tricky points here that you should be aware of when -writing tests: - -- hg commit and hg merge want user interaction - - for commit use -m "text" - for hg merge, set HGMERGE to something noninteractive (like true or merge) - -- changeset hashes will change based on user and date which make - things like hg history output change - - use commit -m "test" -u test -d "1000000 0" - -- diff and export may show the current time - - use -D/--nodates to strip the dates - -- You can append your own hgrc settings to the file that the environment - variable HGRCPATH points to. This file is cleared before running a test. - -You also need to be careful that the tests are portable from one platform -to another. You're probably working on Linux, where the GNU toolchain has -more (or different) functionality than on MacOS, *BSD, Solaris, AIX, etc. -While testing on all platforms is the only sure-fire way to make sure that -you've written portable code, here's a list of problems that have been -found and fixed in the tests. Another, more comprehensive list may be -found in the GNU Autoconf manual, online here: - - http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html - -sh: - -The Bourne shell is a very basic shell. /bin/sh on Linux is typically -bash, which even in Bourne-shell mode has many features that Bourne shells -on other Unix systems don't have (and even on Linux /bin/sh isn't -guaranteed to be bash). You'll need to be careful about constructs that -seem ubiquitous, but are actually not available in the least common -denominator. While using another shell (ksh, bash explicitly, posix shell, -etc.) explicitly may seem like another option, these may not exist in a -portable location, and so are generally probably not a good idea. You may -find that rewriting the test in python will be easier. - -- don't use pushd/popd; save the output of "pwd" and use "cd" in place of - the pushd, and cd back to the saved pwd instead of popd. - -- don't use math expressions like let, (( ... )), or $(( ... )); use "expr" - instead. - -grep: - -- don't use the -q option; redirect stdout to /dev/null instead. - -- don't use extended regular expressions with grep; use egrep instead, and - don't escape any regex operators. - -sed: - -- make sure that the beginning-of-line matcher ("^") is at the very - beginning of the expression -- it may not be supported inside parens. - -echo: - -- echo may interpret "\n" and print a newline; use printf instead if you - want a literal "\n" (backslash + n). - -false: - -- false is guaranteed only to return a non-zero value; you cannot depend on - it being 1. On Solaris in particular, /bin/false returns 255. Rewrite - your test to not depend on a particular return value, or create a - temporary "false" executable, and call that instead. - -diff: - -- don't use the -N option. There's no particularly good workaround short - of writing a reasonably complicated replacement script, but substituting - gdiff for diff if you can't rewrite the test not to need -N will probably - do. +See http://www.selenic.com/mercurial/wiki/index.cgi/WritingTests for +more information on writing tests.