[PATCH 3 of 5] tests: skip new tests with requirements not available on windows
Mads Kiilerich
mads at kiilerich.com
Sat Apr 28 12:36:59 CDT 2012
Idan Kamara wrote, On 04/28/2012 10:16 AM:
> On Sat, Apr 28, 2012 at 3:05 AM, Mads Kiilerich <mads at kiilerich.com
> <mailto:mads at kiilerich.com>> wrote:
>
> # HG changeset patch
> # User Mads Kiilerich <mads at kiilerich.com <mailto:mads at kiilerich.com>>
> # Date 1335568976 -7200
> # Branch stable
> # Node ID dccf7f23e12209ce5fac25e46890d2d4bfe795f4
> # Parent c2257f704c8bcf8ff3b1d8c92bbc9a2e7f651afe
> tests: skip new tests with requirements not available on windows
>
> diff --git a/tests/test-commit-amend.t b/tests/test-commit-amend.t
> --- a/tests/test-commit-amend.t
> +++ b/tests/test-commit-amend.t
> @@ -1,3 +1,5 @@
> + $ "$TESTDIR/hghave" execbit || exit 80
> +
> $ hg init
>
>
> I don't remember testing anything execbit related in
> this test..
>
> Ah, there's a script used as an editor that is chmod +x,
> is there no way around it?
The problem is not so much the chmod but more the different runtime
models for posix and windows which do that creating and launching a
script has some fundamental differences. I could probably also have used
hghave system-sh; it would perhaps have been better to use that - I
didn't check.
> Seems like a waste to throw away a whole test because of it.
I fully agree. This is just a simple and brutal way to make sure that
'running the tests' doesn't produce false errors on Windows ... which
would make the test suite completely worthless. Perhaps one day some
windows users / developers start caring about QA and testing on their
platform and can improve it.
.t tests used to map directly to how a command line session with posix
sh would look like. The recent introduction of python snippets do that
.t tests no longer just can be run on a real command line. (Most test
cases do however still have a simple mapping.)
A next step in that direction could be some kind of test suite cross
platform support for some common 'patterns' - for example 'create a
script that hg can invoke'. Some kind of process control would also help
a lot - right now we have to skip all 'hg serve' tests. The whole
'hghave' system could also be replaced with something smarter and more
efficient. I guess 90% of the invocations of hg are for preparing a
situation where the _real_ test can be done - that could perhaps be
replaced with some command server stuff (unless we want to run the whole
test suite with command server by default...) Reviewing the skipped
tests will probably reveal other ideas.
The primary language of .t tests is posix sh, but we shouldn't assume in
so many places that the platform is posix. Many of the clever sh hacks
we do cause some kind of portability issue anyway.
The 'end' result might be something that has some resemblance to posix
sh syntax but is something different - perhaps based on
http://hg.intevation.org/mercurial/pmezard/pysh/file/ .
/Mads
More information about the Mercurial-devel
mailing list