Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Ramsay Jones [off-list ref] writes:

See commit c7018be509 ("test: allow skipping the remainder", 18-05-2017)
which is currently merged to the 'next' branch (merge 03b8a61e47 of the
'jc/skip-test-in-the-middle' branch).

(see also http://testanything.org)

If you look at http://testanything.org//tap-specification.html, it shows
that you are allowed to annotate a plan of '1..0' with a SKIP directive
to explain why no tests in a file were run. However, a plan with '1..n'
(for any n > 0) must not have any annotation. (Back in 2012, when I wrote
commit bf4b721932, I found much better documentation than the above!)

So, after commit c7018be509, you can now use the 'skip_all' facility
after having run some tests; it now converts that into an 'SKIP comment'
just before the test plan, effectively skipping the remainder of the
tests in the file. (since we are using a 'trailing plan', and have thus
not declared how many tests we had intended to run, we can output an
accurate plan).

Yes, but I consider that c7018be509 is an ugly workaround, not a
part of a properly designed framework.  Unless it is absolutely
necessary to run some tests before we may conditionally want to say
"skip_all/test_done", we should strive to add tests _after_ these
conditional skil_all/test_done is done.

In this case, I do not see there is a strong reason why the new test
must come before the "setup" test.  Sure, it does not use UNCPATH so
the new test may be able to run even when the current path cannot be
spelled as UNC, but that is a natural fallout of (ab)using the test
script that was meant for UNC testing for something else, so I think
a proper way out would be either (1) to use a separate script, if
the new test wants to run whether UNC path can be determined, or (2)
just accept the fact that the new test will only be run when UNC
paths are tested.  Relying on the hack c7018be509 did is much less
appealing.

On 30/05/17 01:03, Junio C Hamano wrote:

Ramsay Jones [off-list ref] writes:

quoted

See commit c7018be509 ("test: allow skipping the remainder", 18-05-2017)
which is currently merged to the 'next' branch (merge 03b8a61e47 of the
'jc/skip-test-in-the-middle' branch).

(see also http://testanything.org)

If you look at http://testanything.org//tap-specification.html, it shows
that you are allowed to annotate a plan of '1..0' with a SKIP directive
to explain why no tests in a file were run. However, a plan with '1..n'
(for any n > 0) must not have any annotation. (Back in 2012, when I wrote
commit bf4b721932, I found much better documentation than the above!)

So, after commit c7018be509, you can now use the 'skip_all' facility
after having run some tests; it now converts that into an 'SKIP comment'
just before the test plan, effectively skipping the remainder of the
tests in the file. (since we are using a 'trailing plan', and have thus
not declared how many tests we had intended to run, we can output an
accurate plan).

Yes, but I consider that c7018be509 is an ugly workaround, not a
part of a properly designed framework.  Unless it is absolutely
necessary to run some tests before we may conditionally want to say
"skip_all/test_done", we should strive to add tests _after_ these
conditional skil_all/test_done is done.

yes, I don't disagree with that (which is why I said that I would
have split t5545 into two files). ;-)

In this case, I do not see there is a strong reason why the new test
must come before the "setup" test.  Sure, it does not use UNCPATH so
the new test may be able to run even when the current path cannot be
spelled as UNC, but that is a natural fallout of (ab)using the test
script that was meant for UNC testing for something else, so I think
a proper way out would be either (1) to use a separate script, if
the new test wants to run whether UNC path can be determined,

Yes, I had intended to suggest this (or an existing script, protected
by the MINGW prerequisite), but forgot!

                                                             or (2)
just accept the fact that the new test will only be run when UNC
paths are tested.

I prefer (1).

                  Relying on the hack c7018be509 did is much less
appealing.

ATB,
Ramsay Jones