On 19 Apr 2006, at 09:02, Ovid wrote:
[snip]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that diag and normal test failure information should be
marked differently (instead of the /^# / that
--- Adrian Howard [EMAIL PROTECTED] wrote:
I've thought in the past about about using /^## / for non-test
related diagnostics
## Start the fribble tests
ok 1 - fribble foo
not ok 2 - fribble bar
# Failed test 'fribble bar'
# in untitled text 2 at line 5.
# got: 'baz'
#
Ovid wrote:
--- Adrian Howard [EMAIL PROTECTED] wrote:
I've thought in the past about about using /^## / for non-test
related diagnostics
## Start the fribble tests
ok 1 - fribble foo
not ok 2 - fribble bar
# Failed test 'fribble bar'
# in untitled text 2 at line 5.
#
(Oops. Accidentally sent this to Michael directly rather than to the
list.)
--- Michael Peters [EMAIL PROTECTED] wrote:
I'm not sure I agree that there is a difference between them. They
are
both comments output by the tests. Just because one comes from the
testing routine used by the test
* Ovid [EMAIL PROTECTED] [2006-04-19 07:20]:
What if someone wants more diagnostic information or more
complete failure information? We might find things useful
enough that that we feel compelled to update TAP. If so, TAP
needs to be versioned and we need to figure out how to
accomodate
On 4/19/06, Ovid [EMAIL PROTECTED] wrote:
to handle got/expected failure information in Java or C? There are
pretty rich data structures we could put out there and YAML might help.
That would also likely simplify a parser.
If you mean you want pluck YAML test results from a noisy input
--- Ovid [EMAIL PROTECTED] wrote:
If you mean you want pluck YAML test results from a noisy input
stream I'd say youd probably be wrong.
Naturally, I forgot to include the most compelling argument. The
noisy input stream is noisy only because we've never tamed it. If it
becomes
* Ovid [EMAIL PROTECTED] [2006-04-19T04:02:31]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that diag and normal test failure information should be
marked differently (instead of the /^# /
* Ovid [EMAIL PROTECTED] [2006-04-19 10:05]:
--- demerphq [EMAIL PROTECTED] wrote:
I should think that youd have a much easier time using
Data::Dumper and its -Pad and -Indent(0) method than you
ever would with YAML.
That fails when we have PHP, C, or Java producing the
information.
* A. Pagaltzis [EMAIL PROTECTED] [2006-04-19 19:10]:
Use JSON. It’s cross-language, can fit data structures on a
single line, is reasonably widely supported, and can even be
read by a YAML parser.
Oh, and I forgot: in contrast to YAML, the spec is so simple
that it’s trivial to cook an
On 4/19/06, Ricardo SIGNES [EMAIL PROTECTED] wrote:
* Ovid [EMAIL PROTECTED] [2006-04-19T04:02:31]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that diag and normal test failure
On Apr 19, 2006, at 12:14, Fergal Daly wrote:
One other reason (that I didn't see mentioned) is that objects imply
that the harness and tests are in the same process which means that
the tests can corrupt the harness and that the harness can fail to
report if the test process dies,
Well, the
On 4/19/06, David Wheeler [EMAIL PROTECTED] wrote:
On Apr 19, 2006, at 12:14, Fergal Daly wrote:
One other reason (that I didn't see mentioned) is that objects imply
that the harness and tests are in the same process which means that
the tests can corrupt the harness and that the harness
I can't remember the exact list off the top of my head.
At the time, I did the cascade tracing by hand using the CPANTS webpage,
it took for-bloody-ever. The only reason I kept doing as deep as I did
was that I kept being astonished at what was getting caught in the web.
There's been
Ovid wrote:
--- David Wheeler [EMAIL PROTECTED] wrote:
Test.Simple—JavaScript. It looks and acts just like tap, although in
reality it's tracking test results in an object rather than scraping
them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Tracking the
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
If that were universally true, we wouldnât have plaintext network
protocols, would we? And I think making TAP a protocol instead of
an API was the right choice.
As already noted, I freely admit I was wrong. If TAP was a Perl only
thing, I might
chromatic wrote:
On Monday 17 April 2006 18:50, Ovid wrote:
The only problem I see with that is the occasional buffering errors I
see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
Unfortunately, it probably is
On Tuesday 18 April 2006 00:20, Ovid wrote:
As a language-independent tool, an API is silly and
I'm a fool for shooting my keyboard off for thinking only about the
implementation problems as opposed to its benefits.
I'm sure you're not the only person who has thought Hey, screen scraping the
* Adam Kennedy [EMAIL PROTECTED] [2006-04-18 09:30]:
especially out there in the darkpan.
What about the deadpan?
SCNR,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Adam Kennedy wrote:
chromatic wrote:
On Monday 17 April 2006 18:50, Ovid wrote:
The only problem I see with that is the occasional buffering errors I
see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec'ed out or documented.
That is
Adam Kennedy wrote:
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec'ed out or
Geoffrey Young writes:
Adam Kennedy wrote:
That is irrelevant. You put something into CPAN, get massive numbers
of people using it, and leave it alone and have it remain stable for
4 years, it becomes an API whether you wanted it to be or not :)
really?
I'm with Adam on this one.
Geoffrey Young wrote:
Adam Kennedy wrote:
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not
--- Adam Kennedy [EMAIL PROTECTED] wrote:
While I agree that this caused problems, those modules were relying
on a
format that was not spec'ed out or documented.
That is irrelevant. You put something into CPAN, get massive numbers
of
people using it, and leave it alone and have it
How non-Perl do you want? Does the Perl 6 version of Test.pm or
Test::Builder/Test::More count? How about the Parrot versions?
Sure, lemme have 'em.
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Test.Simple—JavaScript. It looks and acts just like tap, although
in reality it's tracking test results in an object rather than
scraping them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Can you please give me a short couple of sentences on it for someone
who
Andy Lester wrote:
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
If you know of one, please send me some text to add.
all the big PHP players now produce TAP
o phpt (outputs TAP by default as of
--- David Wheeler [EMAIL PROTECTED] wrote:
Test.SimpleJavaScript. It looks and acts just like tap, although in
reality it's tracking test results in an object rather than scraping
them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Tracking the results in an
--- Andy Lester [EMAIL PROTECTED] wrote:
Since it looks like we're going to stick with reading information
from
a print buffer, we should at least publish an EBNF grammar for the
output.
Patches welcome!
OK, I've a bunch of TPF stuff I'm wrapping up, but if I have some tuits
soon, I'll
Ovid [EMAIL PROTECTED] wrote:
Tracking the results in an object is a better choice than scraping from
a print buffer. One of the frustrating issues with Perl's testing
tools is the limited flexibility we have due to reading the output from
STDOUT.
I like that aspect about TAP... it's
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
If you know of one, please send me some text to add.
Thanks,
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
* Andy Lester [EMAIL PROTECTED] [2006-04-16T23:08:26]
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
If you know of one, please send me some text to add.
It's not really ready to be publicized, and I
* Ricardo SIGNES [EMAIL PROTECTED] [2006-04-16T23:33:19]
It's not really ready to be publicized, and I haven't touched it in a little
while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap
I got a request, off-list, for more info, so here is some:
PyTap will, when it's done,
On Apr 16, 2006, at 20:08, Andy Lester wrote:
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/
TAP.pod
If you know of one, please send me some text to add.
Test.Simple—JavaScript. It looks and acts just like tap,
On Sunday 16 April 2006 20:08, Andy Lester wrote:
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
If you know of one, please send me some text to add.
How non-Perl do you want? Does the Perl 6 version of
36 matches
Mail list logo
