Thanks very much for the explanation,
Tried the following to get the Test/TAP crying...


use Test;
is 1, 1, 'test 1';
say "ok 1 - pestering 1";
say "nok 5 - pestering 2";
done-testing;


It then generates


ok 1 - test 1
ok 1 - pestering 1
nok 5 - pestering 2
1..1
Failed -1/1 subtests

Test Summary Report
-------------------
confuse-TAP.t (Wstat: 0 Tests: 2 Failed: 0)
  Parse errors: Tests out of sequence.  Found (1) but expected (2)
                Bad plan.  You planned 1 tests but ran 2.
Files=1, Tests=2, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.15 cusr 0.01 csys = 0.19 CPU)
Result: FAIL



Looking back in the log I found a line with a test result at the end of the line. This might have been missed by TAP.

2017-01-20 13:04:40.446841 [T] 1: socket found ok 2 - Scanned 200 docs, bad searching


Printing to stderr does not help and I get the same problems with the test above using 'note' instead of 'say'. It then comes down to refraining from printing anything to prevent any mishap. Of course, it is easy to prevent the 'ok ## - something' output but not when some real ok output ends up at the end of some other line.

Btw. the perl version was retrieved from an installation on TRAVIS where rakudobrew is used.

Regards,
Marcel

On 01/20/2017 10:04 PM, Zoffix Znet via RT wrote:
On Fri, 20 Jan 2017 09:16:18 -0800, mt1...@gmail.com wrote:
Hi Will,

How can it happen that a test gets hurt in this way? If I know this I
could better search for the problem.

Regards,
Marcel
Hi,

Here's how that error happens:

The TAP protocol[^1] expects tests to be numbered and (as seen in your output) 
the test harness will complain if it spots tests missing or not in order.

So if your tests produce junk output (that is something other than stuff 
produced by Test.pm6's routines), it could confuse the harness by making it 
interpret junk output as a test.

Another harder way to accomplishing that is to run the tests in multiple 
threads, to trigger a data race in the Test.pm6's internal test counter and 
make it output wrong stuff.

Yet another way is to use a buggy test harness that fails to recognize a test 
and so thinks something's missing. We had such a bug recently, though it got 
introduced on Jan 2nd and got fixed[^2] on Jan 5th. From your version, I see 
you're running Rakudo from some time in October, so this probably isn't it...

I'd suggest you try using a release version of Rakudo or HEAD. I tried running 
that test on my box, but instead of TAP output it seems to be just producing 
time-stamped connection failures.

[1] https://testanything.org/
[2] 
https://github.com/rakudo/rakudo/commit/b120ac401a0795f5f4c5fcd6e775848b4b755508


Reply via email to