Previously, a Test's path came from the base directory of all tests and
a filename leaf. There is not a strong reason why an absolute test path
can not be specified.
This change isn't strictly necessary. But it does enable scenarios such
as more easily running tests from multiple, non-sibling directories.
Mercurial tags can be local (tag -l, stored in .hg/localtags) or global (normal
tags, tracked in .hgtags) ... or extensions can add other kind of tags.
Convert would take all tags (except "tip"), not just the ones from .hgtags, and
put them into .hgtags.
Instead, convert only the global tags that come from .hgtags.
TestResult has facilities for recording when tests start and stop. It
makes sense to move execution time recording into TestResult.
In addition, output generation is being moved into TestResult, a class
that has a concept of an output buffer (and a lock).
Now that we execute all tests via unittest, the MercurialTest wrapper is
not necessary. This patches moves the logic from MercurialTest into Test
and makes Test a child of unittest.TestCase.
The check-code tool now expects the "desc" keyword to be followed by the
"websub" filter, with the following exceptions:
a) It has no filters at all, e.g. a changeset description in the raw style
templates or the repository description in the summary page.
b) It is followed by the "firstline" filter, e.g. the first line of the
changeset description is displayed as a summary or title.
For example, this is useful for linking from the feed reader to a bug tracker.
This follows the existing pattern used within the hgweb templates. With the
exception of the raw style, all usages of the changeset "desc" keyword are now
followed by either the "firstline" filter or the "websub" filter. When "websub"
is used, it always follows the "escape" filter.
Now that unittest mode is functionally equivalent to the default mode,
we switch the default execution mode to unittest and remove the choice
of different execution modes.
Unlike unittest's defaults, our result formatter does not print stack
traces. Here, we change TestResult.addFailure() to be compatible with
the existing/default execution mode.
rmtree() may fail under certain conditions. We ignore failures at the
individual test level because they can interfere with test execution.
Furthermore, we'll reattempt deletion in the high-level test runner
after all tests have finished.
Note that this patch is not a code refactor like most of the patches
before it. This change logically makes sense given the execution
behavior of the tests.
There is an execution mode on run-tests.py that stops after the first
failure. unittest mode was previously not obeying this option. This
patch fixes that.
testtmp is now a member variable of our test class. It's value is
computed during instance creation and the directory is managed via the
lifetime of the test object.
The unittest way of recording a skipped test is to raise an exception
(at least with modern unittest implementation). We change Test to raise
a SkipTest when operating in unittest mode.
This does prevent some "tear down" activities from running in unittest
mode. This will be fixed in subsequent patches. Since unittest mode
is experimental, this should be OK.
Simply wrapping TestCase.run() is not sufficient for robust results
reporting because unittest in Python 2.4 does not know about things
like skipped tests and reports them as success or failures instead of
skips.
We will reimplement TestCase.run() with knowledge and semantics present
in modern Python releases.
unittest does its own printing of progress indicators as part of
TestResult. So, there is no need to print them when running in unittest
mode.
This will fix the double output of progress indicators that had been
occurring in unittest mode.
We now have a custom unittest.TestSuite implementation that uses
_executetests() and thus knows how to execute tests concurrently.
Running tests in --unittest mode will use this TestSuite.
Since the TestSuite handles concurrency, the warnings around --jobs and
--loop have been removed.
Test instances (not paths) are passed into _executetests(). This means
the logic for instantiating Test instances has been moved outside of
_executetests(). This was done because an upcoming patch will reuse the
logic in _executetests().
As part of this change, test counts are no longer managed by
_executetests().
Tests executing in unittest mode behave a little differently. For
example, they report their results to a TestResult rather than just
printing. This patch paves the way for better integration of Test into
the unittest framework.
