chromatic, I think, in that big prove argument, pointed out that Test::More
side-stepped the whole "shove all functionality into one interface" problem by
creating Test::Builder. TAP::Parser and prove should go in the same direction.
Over and above simply being a way to build new test libraries,
On 30 Nov 2007, at 02:51, Michael G Schwern wrote:
I think with TAP there's two central desires.
1) Want to add / change functionality in Test::Harness or prove. For
example, one that adds color, another that saves the TAP results,
another that
emails a report at the end of the test.
Pret
On 30 Nov 2007, at 07:49, chromatic wrote:
I don't believe producer (Test::Builder) and consumer (Test::Harness)
are necessarily entirely alike or symmetrical in this regard. T::B
pushes and T::H pulls - which makes callbacks or some higher level
event driven interface more appropriate for T::H t
On Thursday 29 November 2007 19:21:12 Andy Armstrong wrote:
> I don't believe producer (Test::Builder) and consumer (Test::Harness)
> are necessarily entirely alike or symmetrical in this regard. T::B
> pushes and T::H pulls - which makes callbacks or some higher level
> event driven interfa
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> This is easier to do with Test::Builder because custom features meant
> custom
> functions. Custom functions avoid functionality overlap and users
> write code
> specifically for them. Test::Harness and prove have no such luxury.
Right, let's t
--- Ovid <[EMAIL PROTECTED]> wrote:
> Side note: those features I really want control over in
> Test::Harness
> are the plan() and ok() methods. There's no clean way for me to do
> that. Just look at the constructor:
>
> my $Test = Test::Builder->new;
> sub new {
> my($class) = shift
Ovid wrote:
>> Side note: those features I really want control over in
>> Test::Harness
>> are the plan() and ok() methods. There's no clean way for me to do
>> that. Just look at the constructor:
>>
>> my $Test = Test::Builder->new;
>> sub new {
>> my($class) = shift;
>> $Test |
