On 2011.10.25 10:54 PM, Eric Wilhelm wrote:
> I'm only working from intuition and my understanding of what you
> described as the problem. If you try to implement a few scenarios of
> special handler functionality using each design approach, that might
> help clarify the issues.
All I really h
I keep looking at subtests and keeping thinking that if there wasn't a test
count to manage, would we need subtests? Do we need all that complexity? If
it's just about the test count, can it be managed a better way?
I understand wanting "blocks of tests" and the ability to make plans for just
th
On 2011.10.25 12:29 AM, Eric Wilhelm wrote:
> I like the sound of plan B, except for the "stores itself in" combined
> with "swap me out".
Any specific doubts?
> Can the event coordinator keep a stack? At the point where the parent
> handler has to tell the coordinator "swap me out", you coul
Subtests are the last major feature hurdle for Test::Builder 1.5. They're
kind of a hacky mess in Test::Builder 1 which I don't want to bring forward.
A subtest has to
1) create a separate state of the test
2) change the format of the output
3) communicate the result of the test back to the pare
tl;dr/Executive Summary
---
Harvest the internal improvements from Test::Builder2 for Test::Builder
creating a backwards compatible Test::Builder 1.5 which accomplishes the
lion's share of the grant deliverables. Have a feature complete alpha release
before the end of November.
On 2011.7.14 6:00 PM, Eden Cardim wrote:
> It appears there are several distributions on CPAN whose tests don't
> pass when using several cores. This is an annoyance because some of the
> larger deplists nearly always have a module with broken tests in them,
> so testing can't just be a fire-and-fo
On 2011.4.13 1:50 AM, Jozef Kutej wrote:
> It turned out that there is quite a lot that can go wrong.
>
> Found this gem in our internal wiki. :-)
>
> My question is regarding the post-install testing. Normally the test are run
> before installation and then discarded with all the rest of the dis
On 2011.4.13 1:03 AM, Ævar Arnfjörð Bjarmason wrote:
> We've arranged a laptop with Skype that'll be connected to a beamer.
>
> Can you send me your skype handle so I can have this set up? Thanks.
Thanks! I am cleverly disguised as "Schwern".
If you have Google Video Chat setup as well that wou
Hey folks,
I can't quite make it to the hackathon this year, but I will be able to make
it to Europe. Long story, but at least I'll be on the right side of the planet.
I'd love it if someone could bring a spare netbook with a camera and decent
microphone they can dedicate as a virtual Schwern. T
On 2011.3.31 10:00 AM, Michael Ludwig wrote:
>> Took me a moment to understand that. Would this cover your need?
>>
>> result_like shift @$results, {
>> ...
>> };
>
> That's very good! But does it mess with $history's results directly?
> Or does $history->result return a shallow c
(moving this to perl-qa because we decided to retire test-users)
On 2011.3.30 6:52 AM, Michael Ludwig wrote:
> Michael G Schwern schrieb am 27.01.2011 um 12:09 (+1000):
>> use Test::More;
>> use Test::Builder2::Tester;
>>
>> my $history = capture {
https://github.com/schwern/test-more/tree/v2.00_07
The major change since 2.00_06 is diag() and note() are now hooked into the
event system and the formatters. They're "log" events. See
Test::Builder2::Event::Log for details. This means test failure diagnostics
can now be controlled along with
On 2011.1.31 11:56 AM, brian d foy wrote:
> In article <4d4492ac.6080...@pobox.com>, Michael G Schwern
> wrote:
>
>> Do people not care? Is it going over everyone's heads? Is everyone just
>> waiting for it to be "done"? Does it not seem like TB2 is
When I started Test::Builder2 I gave it its own mailing list so it could have
its own community and not clutter up perl-qa with detailed chatter about
Test::Builder2 and Test::More development.
I don't get much response to posts on test-more-users, though I know people
are subscribed. perl-qa tra
https://github.com/schwern/test-more/tree/v2.00_06
Apparently the way you make me write code is send me to a Linux conference.
This is the sixth alpha release of Test::Builder2 and it is a big one. Maybe
not in lines of code, but in concepts.
The major bits are:
The Design Is Working
--
I'm happy to announce the first rev of Test::Builder2::Tester. It lets you
test Test:: modules without doing string compares on the TAP. You can test a
much wider array of detail and much simpler.
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
Here's an examp
On 2010.10.29 8:36 AM, Pedro Melo wrote:
> All the process got me thinking about Test::Builder. I spent a couple
> of hours tonight trying to see how would I output JUnit with TB2. I
> tried to write a Formatter::JUnit and was mostly successful, but I
> could not see how TB2 ties into the current T
On 2010.10.16 3:29 PM, Fergal Daly wrote:
> I tried to port this import statement to Perl but functions vs methods
> makes a general implementation impossible unless you have knowledge of
> the module being imported. However there's nothing stopping individual
> modules adopting the convention. It'
On 2010.9.28 8:21 AM, Ovid wrote:
> There are no standards that I know of because different situations can call
> for
> different responses. However, be very careful about just mocking everything.
> If
> you do and their API changes, you'll find yourself with passing tests for
code which
> does n
On 2010.9.25 12:15 PM, Shlomi Fish wrote:
> On Saturday 25 September 2010 19:55:59 Andy Armstrong wrote:
>> On 24 Sep 2010, at 22:39, Fergal Daly wrote:
>> [snip]
>>
>>> Thanks. I was hoping to find an active user of the module since they
>>> would have a bit of a head-start and motivation so I wil
I just uploaded to CPAN something called Test-Simple-2.00_01
http://github.com/schwern/test-more/tarball/v2.00_01
This is a technology preview of Test::Builder2. It is by no means
complete or stable, but here's something to play with and see where
it's going.
WHAT TEST::BUILDER2 IS
It is a rewr
On 2010.5.22 3:45 AM, demerphq wrote:
> One thought...
>
> There has been turbulence in the Regexp space over the last versions of perl.
>
> Is it possible these changes might intersect with those changes to
> make it harder to compare regexes?
No, not unless this:
"$regex1" eq "$regex2"
a
On 2010.5.21 1:04 PM, Slaven Rezic wrote:
> Michael G Schwern writes:
>
>> CPAN Testers, please load your smokers with Test::More 0.95_02, compare the
>> results with Test::More 0.94 and report any differences in test results to
>> their respective authors. I would like
Test::Simple/More/Builder 0.95_02 has just been released. I'm proud to say
that I had very little to do with it. All the commits are the work of Nick
Clayton and him not being afraid to flex his commit bit. :)
http://github.com/schwern/test-more/tree/v0.95_02
0.95_01 introduced fixage [1] (my fa
I'm planning out my hackathon trip, and I figure it would be silly to fly all
the way to Vienna, hack, and then fly all the way back home without at least
spending a day or two bumming around. Does anyone else have plans to be a
tourist around Vienna or even broader for a day or two after the c
Joshua ben Jore wrote:
On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern wrote:
A little experimentation with a small disk image shows that close() will
error if there's no disk left. No need to check every print. And a close()
wrapper is trivial. It does mean there needs to be a
Marvin Humphrey wrote:
On Tue, Dec 22, 2009 at 09:03:42PM -0800, Joshua ben Jore wrote:
On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern wrote:
A little experimentation with a small disk image shows that close() will
error if there's no disk left. No need to check every print. And a
Joshua ben Jore wrote:
Fortunately there is one key location where MakeMaker does almost all its
writing to disk, ExtUtils::MakeMaker->flush. A simple patch to check that
would be lovely. If you want to write and insert a safe _print() wrapper
method and scatter that around that's fine, too.
Joshua ben Jore wrote:
The just-released EU::MM 6.56 repeats this pattern frequently:
open my($fh), '>', ...
or croak("Can't open ... for writing: $!");
...
print $fh ...; # <<< no error checking
close $fh ...; # <<< no error checking
Grepping for code:
egrep -rnH '
Jim Cromie wrote:
> What's notable in its absence is any *real* use of perl-dist's tests.
> I dug into the code, and found that this works.
>
> $> HARNESS_TIMER=1 make test
> ext/threads/t/end.ok 60 ms
> ext/threads/t/err...
David Cantrell wrote:
> I vaguely recall someone knowledgeable (Andreas? Dave Golden? You?)
> wibbling about calling CPAN.pm functions from within a script being run
> as a child of CPAN.pm being a bit dodgy, but I guess that that doesn't
> matter if this is only run when you 'make* test' by hand.
I'm in the process of gutting Test::Builder to use Test::Builder2. I figured
the best abuse of Test::Builder is all the testing modules on CPAN. Rather
than continually run them by hand I've added a test which does "dependent
testing", testing of a list of modules which depend on me.
http://gith
Yanick Champoux wrote:
> Elliot Shank wrote:
>> David Cantrell wrote:
>>> On Fri, Jul 31, 2009 at 10:51:57AM -0700, Jonathan Swartz wrote:
Is there a standard for signifying internal-only tests, and for
make test to figure out when they should run?
>>>
>>> The normal way is to have them
http://github.com/schwern/test-more/tree/v0.93_01
Here's another alpha release of Test::More with Ovid's subtest() feature.
This time around it should work fine with all existing test modules.
0.93_01 Mon Jul 20 09:51:08 PDT 2009
Bug Fixes
* Make sure that subtest works with Test:: modu
Ovid wrote:
> - Original Message
>> From: chromatic
>
>> Add diagnostics to TODO tests and let your test harness do what it's
>> supposed
>> to do. Shoving yet more optional behavior in the test process continues to
>> violate the reasons for having separate test processes and TAP an
Erik Osheim wrote:
> On Tue, Jul 07, 2009 at 01:42:23PM -0700, Michael G Schwern wrote:
>> At best you have the ability to group statements together into a test, but I
>> already have that without any intervening pseudo-block to get in the way of
>> debugging.
>
> Do
Adrian Howard wrote:
> 2) Much of the value from Perl's test frameworks come from the stupid
> number of useful testing modules that work happily with each other. I
> can just pick Test::WWW::Mechanise (or whatever) off the shelf and use
> it with the rest of the testing framework.
>
> It's going
Mark Morgan wrote:
> [1] Test::Class is my preferred testing package for work; I don't use
> it for stuff destined for CPAN due to adding an extra dependancy.
> *sigh*
Your CPAN modules already depend on things like Moose and Hook::LexWrap and
XML::Parser. Leaving out Test::Class at that point is
Michael G Schwern wrote:
> Here it is much simpler, and going onto the front of @INC as it should.
>
> use File::Spec;
> BEGIN {
> unshift @INC, map { File::Spec->rel2abs($_) } "t/lib";
> }
>
> If I had to write all that code in every test I'd stran
Shaun Fryer wrote:
> Personally, unless I have a very complicated (and therefore unusual)
> test setup, simply putting .pm files directly in t/ works just fine.
> Then a simple "use lib './t'" does the trick. `prove`, `make test` and
> even Test::Harness::run_tests(glob 't/*.t') ignore anything but
Dave Mitchell wrote:
> On Fri, Jul 03, 2009 at 01:03:59PM -0700, Michael G Schwern wrote:
>> Dave Mitchell wrote:
>>> So unless some other problem comes up, then 0.91 should match both those
>>> goals and everyone's happy.
>> 0.92 is on its way to CPAN with
David Golden wrote:
> On Sun, Jul 5, 2009 at 9:40 PM, Buddy Burden wrote:
>> Let's say I have some common functions that I want available to all my
>> .t files. So I've created a module that all the .t files can include.
>> But where do I put it? I don't want to put it in lib/ because I
>> don't
Ovid wrote:
> I've altered Test::Builder to handle the cases where people are using the TB
> singleton at the top of their test files. You can get a copy at
> http://github.com/Ovid/test-more/tree/master if you want to test it.
I've merged it into schwern/master.
This is my first time maintainin
Dave Mitchell wrote:
> So unless some other problem comes up, then 0.91 should match both those
> goals and everyone's happy.
0.92 is on its way to CPAN with Craig's fixes.
http://github.com/schwern/test-more/tree/v0.92
--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow o
Dave Mitchell wrote:
> On Thu, Jul 02, 2009 at 07:23:31PM -0700, Michael G Schwern wrote:
>> Craig A. Berry wrote:
>>> On Thu, Jul 2, 2009 at 4:03 PM, Michael G Schwern wrote:
>>>> This is a quick release to sync with perl so 5.10.1 can release with a
>>>>
Craig A. Berry wrote:
> On Thu, Jul 2, 2009 at 4:03 PM, Michael G Schwern wrote:
>> This is a quick release to sync with perl so 5.10.1 can release with a stable
>> version number. It does NOT include the subtest() code in 0.89_01 (don't
>> worry, it'll be back).
&
This is a quick release to sync with perl so 5.10.1 can release with a stable
version number. It does NOT include the subtest() code in 0.89_01 (don't
worry, it'll be back).
http://github.com/schwern/test-more/tree/v0.90
0.90 Thu Jul 2 13:18:25 PDT 2009
Docs
* Finally added a note abo
Ovid wrote:
> Also, I think playing around with more fluent interfaces is a good idea.
> If my interface is great, why not? If it's bad, what would people *love*
> to see in a test interface which allows them to naturally write tests?
FWIW I don't see anything about either Ovid's or David's ideas
Ricardo SIGNES wrote:
> * Ovid [2009-06-30T10:21:24]
>> The latest developer release of Test::More allows subtests. Subtests are
>> great in that they solve a lot of problems in advanced Perl testing, but they
>> have required a change in Test::Builder. Previously you could do stuff like
>> this:
Ovid wrote:
> (Helps if I send this from a subscribed address):
>
> From http://use.perl.org/~Ovid/journal/39193
>
> The latest developer release of Test::More allows subtests. Subtests are great
> in that they solve a lot of problems in advanced Perl testing, but they have
> required a change in
Ovid wrote:
> use Test::Sims::Moose 'random';
>
> Person->new(
> name => random('Person.name'),
> age => random('Person.age')
> );
>
> And that would potentially have issues when it assigns "\t" to $name and -12
> to $age
> , even those are both valid values for t
Ovid wrote:
> First feature request: automatic Moose support to build random data which
> conforms to Moose constraints :) (Yes, I know it's much, much harder than
it sounds).
Hello, what?
--
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
Folks might remember my talk at, I think it was YAPC 2008, "Generating Test
Data With The Sims".
http://schwern.org/talks/Generating%20Test%20Data%20With%20The%20Sims.pdf
It was about building up little functions to generate random, but valid, data
and then using those to make random, but valid, o
Ovid wrote:
> - Original Message
>
>> From: Michael G Schwern
>>
>>>> %$Test = %$child;
>>>>
>>>> Watch out for edge cases of when subtest() dies, make sure the
>>>> parent's guts
>>>> get put back.
&
Michael Peters wrote:
> Michael G Schwern wrote:
>
>> A simple strategy might be to just replace the global singleton with the
>> child's guts at the start of a subtest() and then back out again at
>> the end.
>>
>> %$Test = %$child;
>>
>>
Ovid wrote:
> - Original Message
>
>> From: David E. Wheeler
>> To: Ovid
>> Cc: perl-qa@perl.org
>> Sent: Monday, 29 June, 2009 17:38:15
>> Subject: Re: Subtest fail with singletons
>>
>> On Jun 29, 2009, at 2:19 AM, Ovid wrote:
>>
>>>my $Test = Test::Builder->new;
>>>
>>> If every
David E. Wheeler wrote:
> On Jun 24, 2009, at 9:59 PM, David Golden wrote:
>
>> As long as we're bike-shedding, a simplification:
>>
>> subtest {
>>plan "sanity check" => 3;
>>pass for 1 .. 3;
>> }
>>
>> Anything other than "no_plan" or "skip_all" is taken as if "tests".
>
> I thought o
Paul Johnson wrote:
> One question though. Why
>
> subtest "text", sub {};
>
> rather than
>
> subtest {}, "text";
>
> ?
>
> The latter seems more consistent as well as removing a rather annoying bit of
> syntax. Were you worried that "text" might get lost at the end of the sub?
Not
This is an alpha release of Test::More available on CPAN and from its
repository.
http://github.com/schwern/test-more/tree/v0.89_01
subtest()
-
Small change log, big feature. This version adds subtest(), implemented by
Ovid. This allows you to run a bunch of tests with their own plan.
Ovid wrote:
> Yeah, I can deal with all of this. I think the main thing is that any
> YAML diagnostics which accept arbitrary keys added will have to:
>
> a. Reject any key matching /^[[:lower:]]/ (or is /^[a-z]/ really preferred
> here?)
The simple ASCII/UTF8 a-z avoids wacky locale issues wh
Gabor Szabo wrote:
> Anyway here is another thing that I found.
> The test script fetches a few rows from a database and prints out a
> nicely formatted
> table of the values using high quality ascii art:
>
> 1 | 3 | foo
> 1 | 7 | bar
>
> I can just print the array holding this using explai
Gabor Szabo wrote:
> I recall that we talked about a possibility to emit yamlish but the last thing
> I remember was the discussion about lower or upper case names...
> Was there a progress in that subject ?
tl;dr version: Yes, its resolved at least to Ovid and I's satisfaction who
were the two mo
Andy Armstrong wrote:
> On 10 Jun 2009, at 16:12, Ovid wrote:
>>> I can probably make a release that does within a few days if that's
>>> the kind of
>>> thing that Gabor needs.
>>
>> If we can get buy-in from Schwern, what about forking
>> https://github.com/schwern/test-more/tree and adding it th
Gabor Szabo wrote:
> So now that I am switching reporting to TAP how do I log the raw data?
>
> So far I could think only to either create a log file with the raw data or to
> print the raw data using diag().
> In the former case I lose the single result file advantage and I'll have
> to somehow m
Andy Lester wrote:
>
> On Jun 9, 2009, at 2:57 PM, Michael G Schwern wrote:
>
>>> use Test::More tests => 14;
>>> ok( 1 );
>>> done_testing();
>>
>> You would try that. :P
>
>
> It's not that I tried it, it's that I did
Andy Lester wrote:
> I'm so glad for done_testing(). I don't like no_plan, but
> done_testing() makes it better.
>
> I was surprised/confused to see this behavior:
>
> $ cat foo.t
> use Test::More tests => 14;
> ok( 1 );
> done_testing();
You would try that. :P
I guess its a belt and suspender
Rather than spring it on the world on a holiday weekend, I'm going to release
Test::More 0.88 on Wednesday pending any horrible screaming.
There's a small but potentially incompatible change since 0.86 in that you no
longer need to specify a plan before running a test. This allows the new and
lon
Executive Summary: Not a bug. The whole idea of putting .pm files outside
lib is wonky. A warning from MakeMaker wouldn't hurt but I'm unconcerned with
the whole problem.
Smylers wrote:
> I recently encountered a Cpan module which doesn't install from its
> distribution yet passes all its test
I'm doing some application/acceptance level testing of web apps. Selenium is
one option but for things like "check that every item has X attribute set" I
really want a program. Javascript isn't a big deal so I wrote up some
Mechanize scripts.
A lot of the information isn't particularly friendly
Jonathan Swartz wrote:
> 2) I have to compute the right exception paths. Doing "use lib
> qw(blib/lib blib/arch)" as you suggest would only work if the tests were
> run from the main directory. e.g. If I'm in the t/ directory and do
> "perl -I../lib foo.t", as I do sometimes, it ought to work as we
Gabor Szabo wrote:
> So I think - besides the fact that M::I probably should not load the
> required modules to memory
That was fixed in MakeMaker 6.51_01 at Adam Kennedy's request. So it'll
trickle down to Module::Install.
--
'All anyone gets in a mirror is themselves,' she said. 'But what yo
Saftoiu, Rares wrote:
> Smolder sounds great for viewing the results, I was looking for something
> that could deal with branches. We branch on every bug fix, and then when the
> fix is done we push that branch to a particular directory, so at the end of
> a bug fix cycle we have a bunch of branche
Thomas Klausner wrote:
> Is there any module on CPAN (or some other accepted technique) to
> maintain some kind of state between tests?
>
> I know that this will kill parallel testing, but I'm trying to test a
> rather long process involving several files and several steps, factored
> into seve
Jonathan Rockway wrote:
> * On Wed, Apr 08 2009, Michael G Schwern wrote:
>> # Moose
>> sub DOES {
>> return $_[0]->meta->does_role($_[1]);
>> }
>>
>> # Class::Trait
>> sub DOES {
>> return $_[0]->does($_[1]);
>> }
>
&g
Ovid wrote:
> Moose:
>
> if ( $object->meta->does_role($some_role) ) { ... }
>
> Class::Trait:
>
> if ( $object->does($some_role) ) { ... }
>
> 5.10 ad hoc support?
>
> if ( $object->DOES($some_role) ) { ... }
>
> We have an internal Test::Most I've hacked to support this and it works f
Ricardo SIGNES wrote:
> * Michael G Schwern [2009-03-31T18:22:50]
>>> What if display types could be provided informationally in the TAP stream.
>>> The stream could include:
>>>
>>> want: foo bar
>>> have: foo bar
>>> presenta
David Golden wrote:
> On Tue, Mar 31, 2009 at 6:22 PM, Michael G Schwern wrote:
>> But it's really more useful for more complicated formatting. Something
>> simple
>> like making subtle whitespace differences visible should be a feature of the
>> TAP consumer.
&
Ricardo SIGNES wrote:
> I'm mostly sending this email because I had an idea, and it's late, and I
> don't
> want to forget.
>
> Today it occured to me that many Test:: extensions are more about better
> diagnostic output than better test comparison.
>
> This stinks:
>
> want: foo bar
> have
Evgeny wrote:
> Super! Well done!
>
> Makes me feel all warm inside.
>
> Would kiss you if you were near here somewhere! :)
I'm kind of glad I'm not, but thank you all the same.
--
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Thing
Steffen Schwigon wrote:
> 1. I have collections of TAP with YAML but missing "TAP version 13"
>prefixes, which influences the yaml recognition.
>
>Can I tell TAP::Parser to assume a particular version (ie., 13)?
>
>Else I need to prepend it by myself, this would at least work on my
>
Just pushed out a new alpha of Test::More. There's a bunch of new features
having to do with the plan. In general it's less restrictive, you can now run
tests without first having declared a plan.
This enables the long called for new feature of done_testing(). It's a safer
replacement for no_pl
Ovid wrote:
> That's the main reason why our tests don't run on production right now. I
> would like, at the very least, to have a './Build sanity' target to ensure
> that guaranteed non-destructive tests are run, but the strange argument I'm
> facing is that "production should be an exact copy
Paul Johnson wrote:
> On Thu, Mar 26, 2009 at 08:46:37AM -0700, Ovid wrote:
>
>> We have someone arguing that when our Perl apps move from staging to
>> production, we must not run "make test" because:
>>
>> 1. It's guaranteed to be 'bit-by-bit' identical to staging.
>> 2. Downtime must be minim
David Golden wrote:
> On Mon, Mar 23, 2009 at 3:56 PM, Michael G Schwern wrote:
>> I ask not for myself, I know the answers to this and they suck. I've bitched
>> about this before and its not necessary to go into details again. I ask as
>> Joe Newbie CPAN Author who
Barbie wrote:
> On Mon, Mar 23, 2009 at 12:56:43PM -0700, Michael G Schwern wrote:
>> There are two URLs in the report. One is for the main cpantesters.org site
>> which is too broad. The other is supposed to point at information about how
>> to fix the failure, but the site
DNA.pm failed its tests. I want to reassure the smoker that this is actually
normal, or at least part of the joke. It mutated. :)
Here's the failure report:
http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3537903.html
Now, where are the instructions on how I respond? How do I corre
I don't think we've every discussed if posting jobs here is a no-no, but I
thought people might be interested in knowing that Mozilla is looking for a
"QA Execution Engineer" with the possibility of it being a remote job.
http://www.jobvite.com/CompanyJobs/Job.aspx?c=qpX9Vfwa&v=1&j=oVybVfwj
"Mozi
Fergal Daly wrote:
> Alternatively, the plan is a meta-test, a test for your testing code.
> It is the equivalent of putting
>
> is($tests_run_count, $tests_i_planned_count)
>
> at the end of your test script. Letting the computer calculate the
> plan is the equivalent of putting
>
> is($tests_r
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Monday 16 March 2009 11:47:
>
>> I suppose what really covers their ass is that by being broken up into
>> test_* routines each test function is isolated and their code is
>> simpler and less likely to have a logic e
Andy Lester wrote:
>
> How about we put up a page somewhere that discusses the pros and cons of
> counting tests, and then whenever the quarterly discussion of LOLZ YOU
> ARE COUNTING YOUR TESTZ FOR NO REASON! vs. YOU DON'T KNOW WHAT HAPPENS
> WITHOUT A PLAN N00B! rears its head, we can refer peop
Evgeny wrote:
> The know:
> - how many unit tests were executed each run
> - how much time each unit test took to run (and the total time)
> - which unit tests passed, and which failed
> - the behavior of some tests over time (a bad test can randomly
> fail/pass for example)
As an aside, have a lo
Adrian Howard wrote:
>
> On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
> [snip]
>> The test numbering exists to ensure that all your tests run, and in
>> the right
>> order. XUnit frameworks don't need to know the number of tests
>> because they
>&g
Fergal Daly wrote:
> [oops sending to the list this time]
>
> 2009/3/13 Ovid :
>>
>> From: Josh Heumann
>>
>>> In that case, the way to generate well-formed TAP seems to be to put the
>>> END block above the use statement, which either means an end statement
>>> a
Let's sum up.
The "why can't a program count its own tests" page refers to the problem of
counting the tests *without* running the code.
`use Test::More "no_plan";` is the most used way to run a test without having
to hard code the number of tests beforehand.
The test numbering exists to ensure
Steffen Schwigon wrote:
> Somewhat related to Andy Lesters problem some days ago about the TAP
> of "prove --verbose" should not be touched.
>
> Is it possible to make the output "idempotent", i.e., that I can take
> the output of "prove --verbose" and parse it again with same results?
>
> In par
Just some prove tricks I thought I'd pass along.
Parse TAP from a file, rather than program output. Handy for doing
experiments without having to mock up a program.
$ cat ~/tmp/foo.tap
1..2
ok 1
ok 2
$ prove --exec 'cat' ~/tmp/foo.tap
/Users/schwern/tmp/foook
All
David E. Wheeler wrote:
> On Feb 21, 2009, at 10:54 PM, Michael G Schwern wrote:
>
>> There is Perl 5 style backwards compatibility where you never, ever break
>> anything for years and years and years and even for code that you're
>> not sure
>> even exists.
David E. Wheeler wrote:
> On Feb 21, 2009, at 5:44 PM, Michael G Schwern wrote:
>
>>> Yeah, I'm suggesting this more for a new version of TAP.
>>
>> It won't work because it's not backwards compatible.
>
> I care less and less about backwards compa
David E. Wheeler wrote:
> On Feb 21, 2009, at 11:35 AM, Michael G Schwern wrote:
>
>> David E. Wheeler wrote:
>>> Dot notation?
>>>
>>> ok 1.1
>>> ok 1.2
>>> ok 2.1
>>> 1..2
>>
>> If you don't want any existing TA
David E. Wheeler wrote:
> Dot notation?
>
> ok 1.1
> ok 1.2
> ok 2.1
> 1..2
If you don't want any existing TAP parser to be able to read it and delay
release until they do, sure!
I am totally not waiting for TAP to work out sub-plan syntax.
--
185. My name is not a killing word.
-- Th
101 - 200 of 1799 matches
Mail list logo
