On Sun, May 03, 2015 at 12:34:59AM +0200, Aristotle Pagaltzis wrote:
> * Sawyer X <xsawy...@gmail.com> [2015-05-02 23:05]:
> > Effectively what happened/happens is that, while plugins are now able
> > to provide two different implementations without worrying about
> > backwards compatibility (we originally wanted it to be seamless but
> > turned out to be very hard), most plugins had a shared core. This was
> > odd to maintain. You either fork it or you put it in a common "::Core"
> > module, or you ship both in the same distribution.
>
> I was going to suggest shipping both in the same distribution – in fact
> if the code is completely identical you could put them in one file and
> basically just alias one namespace to the other, which seems desirable
> as it reduces the maintenance burden to “essentially free” – but there
> is a problem with that: dependencies and testing.
Not exactly replying in the right place, but I'm not sure where's the best
place to reply. Also, I have only glanced at Test::Stream's documentation,
so it might also have the issues I'm describing below.
One issue with the old system, if I understand correctly, is that because
of Test::Builder's design (which maintains state and counters et al.),
any test script that uses a Test:: module that depends on Test::Builder
CANNOT output part of its TAP by any other mean:
$ perl -MTest::More -e 'plan tests => 2; ok(1); print "ok 2\n"'
1..2
ok 1
ok 2
# Looks like you planned 2 tests but ran 1.
To me, the above is a limitation of Test::Builder.
I'm sure an example with done_testing would yield even more "interesting"
results[1] on which `prove` would choke.
So, using something based on Test::Builder in combination with ANY
other TAP-producing mechanism is going to break. And that is entirely
Test::Builder's fault.
Given that this limitation already exists, saying that "a test
module based on Test::Stream can't be used with a test module based on
Test::Builder in the same test script" remains an issue with Test::Builder
wanting to keep all the state for itself, and ignoring the rest of the
(future) world.
Basically, one of the ecosystem is already excluding all the others,
and that is not fixable...
So, what I understand to be the perceived limitation of Test::Stream
(not being able to run in combination with Test:: modules built with
Test::Builder in the same test script) can be blamed on Test::Builder.
And therefore, saying that Test:: modules based on *anything else* than
Test::Builder are incompatible with those based on Test::Builder is
actually just fine.
So yeah, Test2. Or, if the new architecture does not have the same
limitation, some entirely new top-level namespace, like Check::,
Trial::, etc.
[1] That might also be a data point for saying that a plan ending a
TAP stream should not be required to produce the correct test count,
or at least, should be allowed to declare "I'm done, but I've got no
idea how many tests I ran".)
--
Philippe Bruhat (BooK)
None suffer so much in a war as those who strive to end it.
(Moral from Groo The Wanderer #51 (Epic))
