A. Pagaltzis wrote:
> I don’t think you’re overly conservative when it comes to app
> data, but I agree with Ovid that this is bad separation of
> concerns. How dates in app data are handled should be up to the
> app to define. I think we should restrict this proposal solely to
> datetimes in TAP m
Ovid wrote:
> Whoa! I missed a memo and now I'm confused. I did think that a lot of
> this fuss over the date YAML meta information in TAP was going on a
> bit, but small details can be important. However, date YAML diagnostic
> information (we need formal names to distinguish between those two)
* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-06 23:40]:
> For example, let's say you're testing some Biblical software
> and want to make sure you got your dates right.
>
> not ok 1 - age of the Earth
>
> found: -050-02-12
> wanted: -4004
# from Michael Peters
# on Thursday 06 September 2007 01:49 pm:
>Ovid wrote:
>> Thanks for reminding me. Another bit of meta-information that
>> should be optionally supported in the TAP YAML output is "duration".
>> If one's comparing the behavior of a test suite over time, some
>> might find i
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> A. Pagaltzis wrote:
> >> If they're really not useful and just complicate matters I'm
> >> quite open to being convinced otherwise.
> >
> > OK; the goal here, I think, is to make TAP as simple as possible
> > to generate as well as consume, witho
On 05/09/07, Fergal Daly <[EMAIL PROTECTED]> wrote:
> On 05/09/07, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > I would like to compare data structure in some non-test code.
> > Test::Deep seems to give all the features I need, except that it is
> > integrated with
> > the testing framework.
>
> use
A. Pagaltzis wrote:
>> If they're really not useful and just complicate matters I'm
>> quite open to being convinced otherwise.
>
> OK; the goal here, I think, is to make TAP as simple as possible
> to generate as well as consume, without limiting expressiveness
> unnecessarily.
Yep, we're on the
Michael Peters wrote:
> Ovid wrote:
>
>> Thanks for reminding me. Another bit of meta-information that should
>> be optionally supported in the TAP YAML output is "duration". If one's
>> comparing the behavior of a test suite over time, some might find it
>> beneficial to know that they've added
Ovid wrote:
> Thanks for reminding me. Another bit of meta-information that should
> be optionally supported in the TAP YAML output is "duration". If one's
> comparing the behavior of a test suite over time, some might find it
> beneficial to know that they've added 10% more tests but increased
--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> The question is, do we need that flexibility? As far as I can
> tell, datetimes in TAP would almost always denote instants in
> time, not durations nor long-duration recurring events, and it
> will always be easy to come up with the current month and
* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-04 23:35]:
> A. Pagaltzis wrote:
> > Actually ISO 8601 gives many more options than RFC 3339,
> > which is why the latter was written in the first place. See
> > 5.3 (“Rarely Used Options”) in RFC 3339.
>
> That's why I'm inclined to go with one bas
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> $tb->plan("no_plan");
> $tb->no_diag(1);
> $tb->no_ending(1);
> $tb->no_header(1);
> $tb->output( File::Spec->devnull );
In that case, can I request the following?
sub Test::Builder::quiet {
my $self = shift;
$self->plan("no_plan")
Gabor Szabo wrote:
> I would like to compare data structure in some non-test code.
> Test::Deep seems to give all the features I need, except that it is
> integrated with
> the testing framework.
>
> How could I use that or what else should I use to compare two deep
> data structures?
Here's how
13 matches
Mail list logo
