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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]