On 20 Apr 2006, at 16:55, Michael Peters wrote:
[snip]
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 and the other from the test itself
doesn't mean they aren't both just
(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 t
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
--- 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: '
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 /^# / tha
* Fergal Daly <[EMAIL PROTECTED]> [2006-04-19T15:24:51]
> On 4/19/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> >
> > There are other things that test test output, like Test::Tester. Will they
> > break? To find out, I downloaded a pristene copy of the latest Test-Simple
> > and Test-Tester and
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 failu
* 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 imp
* 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
> i
* 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]> 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 well-
--- demerphq <[EMAIL PROTECTED]> wrote:
> 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 mea
12 matches
Mail list logo