Michael G Schwern wrote:
Is it possible to standardize this, so a generic harness knows
which test a comment line acctually describes?
I'm going to call a big, fat YAGNI on this one for the time being. It
requires a change to both the protocol and testing libraries for a minimal
organizational im
On 2005-02-25, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
> I'm going to call a big, fat YAGNI on this one for the time being.
I looked that one up. :)
You Aren't Going to Need It.
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
I like it.
Mark
--
http://mark.stosberg.com/
On Fri, Feb 25, 2005 at 10:22:33AM -0500, Joe Schaefer wrote:
> > More to the point is its completely unstructured output that comes not
> > as part of the test but between them.
>
> It might be worthwhile to associate that "unstructured output" with
> a particular test (either the previous "ok/n
[EMAIL PROTECTED] (Michael G Schwern) writes:
[...]
> More to the point is its completely unstructured output that comes not
> as part of the test but between them.
It might be worthwhile to associate that "unstructured output" with
a particular test (either the previous "ok/not ok" line, or th
On Thu, 2005-02-24 at 14:19 -0800, Michael G Schwern wrote:
> Is this associated with the recent versions of TH that attempt to capture
> STDERR?
I redid that patch, removing that dubious feature, and I think Andy
applied the second version. T::H::S now interprets any diagnostics and
associates
On Feb 24, 2005, at 2:19 PM, Michael G Schwern wrote:
Is this associated with the recent versions of TH that attempt to
capture
STDERR?
No, all my patch did was turn off buffering in the same way that
Test::Builder does.
Regards,
David
On Wed, Feb 23, 2005 at 08:05:13PM -0800, David Wheeler wrote:
> >The way Test::Builder works, diagnostics always go to STDERR. Is there
> >a reason for this beyond "It's tricky to correlate diagnostics to the
> >appropriate test numbers"? (I agree with that, but I'm willing to take
> >my chances
On Wed, Feb 23, 2005 at 06:42:57PM -0800, chromatic wrote:
> The TAP documentation in 2.47_01 says:
>
> A harness must only read TAP output from standard output and not from
> standard error.
>
> The way Test::Builder works, diagnostics always go to STDERR. Is there
> a reason for this bey
On Thu, Feb 24, 2005 at 09:48:59AM -0500, Joe Schaefer wrote:
> Agreed. IMO the TAP protocol should confine itself to a single
> (arbitrary) data stream. It shouldn't even specify STDOUT;
> leaving that as an implementation detail makes the protocol more
> useful (ie., we should be able to commu
Joe Schaefer wrote:
> we should be able to communicate TAP via HTTP, SMTP, etc.).
TAP::Lite anyone?
/me ducks
;)
--Geoff
[EMAIL PROTECTED] (David Wheeler) writes:
> On Feb 23, 2005, at 6:42 PM, chromatic wrote:
>
>> The way Test::Builder works, diagnostics always go to STDERR. Is there
>> a reason for this beyond "It's tricky to correlate diagnostics to the
>> appropriate test numbers"? (I agree with that, but I'm
On Feb 23, 2005, at 6:42 PM, chromatic wrote:
The way Test::Builder works, diagnostics always go to STDERR. Is there
a reason for this beyond "It's tricky to correlate diagnostics to the
appropriate test numbers"? (I agree with that, but I'm willing to take
my chances on certain occasions.)
Perso
A harness must only read TAP output from standard output and not from
standard error.
I wasn't considering the diagnostics to necessarily be TAP output.
They're allowed, but not necessary to the running of the test.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Hi there,
The TAP documentation in 2.47_01 says:
A harness must only read TAP output from standard output and not from
standard error.
The way Test::Builder works, diagnostics always go to STDERR. Is there
a reason for this beyond "It's tricky to correlate diagnostics to the
appropriate
14 matches
Mail list logo
