On Aug 21, 2006, at 09:43, Ovid wrote:
If I've spent a lot of time building something that is deemed
unsuitable for the future direction of TAP and the testing
framework, I really don't want to continue working on it. If it
*is* suitable but needs some work, I'd like to know that, too.
I
On Sep 4, 2006, at 07:19, Ovid wrote:
Actually, I'm not sure how this would break anything and *I* don't
see a problem with it, but since the current behavior is to use
separate file handles, I'm not sure if there's anyone relying on
the current behavior. However, given that it's so widesp
On Sep 4, 2006, at 10:58, Andy Lester wrote:
I think I might just JFDI a "T::H goes to STDOUT" release.
That won't preveing T::B from sending output to two different file
handles…
Best,
David
On Sep 21, 2006, at 17:43, Michael G Schwern wrote:
The hack will only work for Test::Builder based tests. I said this
last month when it came up. You could write a hack for Test.pm
too, but not everyone uses Test.pm either. You're going to
continually be writing hacks for different test
On Sep 29, 2006, at 16:00, Ovid wrote:
There are all sorts of little details there, but basically,
got/expected (or whatever names are settled on) are to be free-form
text. The main question is whether or not those forms are HERE
docs or
follow a pseudo-YAML convention).
I find the YAML ve
On Oct 4, 2006, at 13:18, brian d foy wrote:
I tried those a long time ago. I wanted something interactive that
doesn't rely on external programs.
It should probably use Text::Aspell under the hood, if it can.
Best,
David
On Oct 17, 2006, at 16:37, Michael G Schwern wrote:
Umm, which ones? I guess Test.Simple has a parser.
No, Test.Simple does no parsing. It reads a data structure. So you
should probably call it an emitter.
Best,
David
On Nov 9, 2006, at 18:20, Adam Kennedy wrote:
I'd be interested in people's thoughts about this sort of non-
testing use of TAP/Test::More/etc.
What you say makes a lot of sense to me. I mean, it's the test
*anything* protocol. Makes sense to test the various steps of your
deploy scripts a
On Jan 9, 2007, at 3:05 AM, Adam Kennedy wrote:
Just some tips I thought I'd pimp... ewr... I mean pass on.
Obviously, you should call it `pimp` rather than `pip`. Probably
isn't used by any other program in the universe, either. ;-)
—David
On Mar 31, 2007, at 21:06, Shlomi Fish wrote:
Maybe so, but how else can CPANTS detect that you use the world's
most
advanced version control system: CVS?
Are you kidding?
Methinks you are not familiar with chromatic's sense of humor. Most
people aren't, though, especially in email. :-)
On Apr 17, 2007, at 03:14, Ovid wrote:
Test::Automock would simply use autoload to capture all method calls
and their arguments. Methods by default would return a true value
unless specifically overridden. I'd have to do tricks like overriding
isa() and friends, but that seems like it would be a
A bit late on the reply here, but…
On Aug 19, 2007, at 05:44, Ovid wrote:
By historical accident, virtually all tools expect that tests are in
test.pl or the 't/' directory. Merely by taking advantage of this and
using a different, standard directory, we avoid breaking any of those
tools. A n
On Sep 17, 2007, at 03:55, A. Pagaltzis wrote:
• SVN::Notify (html.t)
use_ok() is not in a BEGIN block in that file, so it should be fine,
yes?
Thanks for doing that search, though, very cool!
Best,
David
On Nov 28, 2007, at 02:17, Ovid wrote:
I would like to be able to provide the tests run via 'prove' with
options something like this:
some_variant_of_prove t/*.t --option1 --option2 arg1 arg2
... where those 4 command-line options/arguments would be available
to
*each* of the individual tes
On Nov 29, 2007, at 04:20, Andy Armstrong wrote:
[X] --
[ ] something else (please specify)
Best,
David
On Nov 29, 2007, at 03:34, Ovid wrote:
Could we not add a feature to prove and/or runtests such that, any
arguments after a bare "--" will be passed on to the scripts it
runs?
I've often wanted this myself, and --exec seems like overkill to
me.
Seconded.
Just to clarify, --exec *is* overk
On Feb 24, 2008, at 12:02, Michael G Schwern wrote:
Test::Builder dups STDERR and STDOUT, this is so you can mess with
them to your heart's content and still get testing done. File I/O
disciplines don't appear to be copied across dups. That's what
everyone was complaining about, that they
On Apr 11, 2008, at 03:59, Michael G Schwern wrote:
Quite rapidly everyone shifted over to thinking that we should only
allow
"X-foo" for user keys because it's unambiguous. Then we don't have
to worry
about characters that don't have an up/down-case concept. And we
can eyeball
a user vs
On Apr 11, 2008, at 06:13, Ricardo SIGNES wrote:
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
I thought this had been the resolution. I hope it *is* the formalized
resolution. It is simple and easy and leaves
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
B) Reserve "lower case" and
On Apr 13, 2008, at 11:37, Michael G Schwern wrote:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can
use.
I don't have any particular reason. Just a feeling t
On Apr 13, 2008, at 15:58, chromatic wrote:
The problem with an infinitely expandable protocol that tries to do
everything
is that it's infinitely expandable and tries to do everything.
Might be nice
to rein that in a little bit more. Or don't, and instead make it
trivial to
add ad-hoc ke
On Apr 17, 2008, at 22:44, chromatic wrote:
I don't know how to put this any more clearly, so I'm content to let
this
thread die here and watch TAP v15 careen off into crazy town.
(Alternately,
I could be the one careening off into crazy town, but at the risk of
making
an argument from aut
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However,
the first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes. The choices, as I see th
On Apr 19, 2008, at 08:15, Michael G Schwern wrote:
#3 is just #2 following an existing cow path. In short, we have a
good idea that official vs user is going to be a problem. Is anyone
arguing it won't? We have a simple, elegant solution to it that
doesn't cause another problem. The cost
Hey all,
I just wanted to mention that I've "ported" Test::More to PostgreSQL.
Yes, you heard right. Details here:
http://justatheory.com/computers/databases/postgresql/introducing_pgtap.html
The project page for it should appear here in a day or two:
http://pgfoundry.org/projects/pgtap
On Jun 10, 2008, at 14:10, Aristotle Pagaltzis wrote:
Hi David,
I think you wanted to send this to [EMAIL PROTECTED]
I guess. I'm not on that list. I was just thinking, do QA in SQL!
Best,
David
On Jul 25, 2008, at 19:52, Andy Lester wrote:
It's more than that.
I know, but that "OMG THAT'S JUST SQLITE" is the #1 comment I've
been seeing.
That has been my reaction. I do assume, though, that aside from
Jonathan Rockaway's comments that seem to justify the suspicion that
it's jus
On Jul 26, 2008, at 20:32, Aristotle Pagaltzis wrote:
That has been my reaction.
SQLite has far more features. Compared to a full RDBMS, SQLite is
an RDBM without the S – Drizzle is more of a… DMS. Essentially it
goes back to MySQL’s flatfile-with-quasi-SQL-frontend roots.
Whether they take of
On Aug 6, 2008, at 20:12, Michael G Schwern wrote:
So I encourage folks to use "have" and "want" in the future. I'll
be using them in Test::Builder2.
Good call. Change committed to pgtap and Test.Builder.
Thanks,
David
Howdy,
I've started fiddling with the stdout option to TAP::Harness. It's
nice, although it doesn't capture everything. I mean, I think it does,
but stuff still gets sent to STDOUT, too. The best way to keep stuff
from also going to STDOUT appears to be to set verbosity to -2
-2 rea
On Aug 18, 2008, at 02:53, Ovid wrote:
Also, pulling in people developing TAP for things other than Perl
would be good (such as David Wheeler's PostgreSQL work. That came
up a few times as uri/line# diagnostic information isn't quite as
applicable there).
Well, it would be handy if I cou
On Aug 18, 2008, at 07:03, Ovid wrote:
Those are certainly important issues, but JSON will make some of
them trivial. The YAML types, embedded documents and the "one
format to rule them all" concept is precisely what makes it
unsuitable for TAP. That's a damned shame because if there was
On Aug 18, 2008, at 15:08, Ovid wrote:
--- On Mon, 18/8/08, David E. Wheeler <[EMAIL PROTECTED]> wrote:
But I don't have file or line numbers in Test.Builder
(JavaScript). I
don't believe it's possible to get that info in JS,
is it?
This is precicely part of the rea
On Aug 20, 2008, at 09:57, David Golden wrote:
Anyway. I am in the "Keep MANIFEST in repo and manually update" camp.
Me, too, usually. I like to have the repository tag for a release
contain exactly the files in the tarball on CPAN. This includes things
like META.yml.
+1, although I recentl
On Aug 20, 2008, at 13:37, David Golden wrote:
This all built up over years as I tried to automate away each stupid
distribution packaging mistake I've made in releasing something to
CPAN.
This should be a module. I'd use it.
Best,
David
On Aug 20, 2008, at 14:58, Eric Wilhelm wrote:
Of course, by trying to make it abstract and reusable, I'm just making
unnecessary work for myself because every author with more than 3
modules writes their own kit? At least, that's the impression I get
whenever I mention it.
I don't have one.
On Aug 21, 2008, at 08:06, Paul Johnson wrote:
On Thu, Aug 21, 2008 at 10:09:32AM -0400, Christopher H. Laco wrote:
I've got one at home now that also has .rb files...
Why .phpt instead of .php?
Why not .t for every language?
Because that's how the harness knows what program to execute: P
On Aug 21, 2008, at 06:55, Thomas Klausner wrote:
unexpected consequences. It also highlights the issue of
Test::Harness's long-standing practice of stripping the .t extension
from filenames. Why? If we want other extensions, stripping them is
probably bad.
FYI, when I run both .t Perl and .s
On Aug 21, 2008, at 09:57, Ricardo SIGNES wrote:
Schwern would like it to be YAML (a superset of JSON), with the
phrasing
"consumers MUST understand JSON and SHOULD understand YAML."
+1
David
Howdy,
When I run the pgTAP tests through pg_prove, which uses TAP::Harness,
it looks like this:
% pg_prove -d try sql/*.sql
psql --dbname try --no-psqlrc --no-align --tuples-only --pset
pager= --pset null=[NULL] --set ON_ERROR_ROLLBACK=1 --set
ON_ERROR_STOP=1 --set QUIET=1 --file
On Aug 21, 2008, at 12:09, Andy Armstrong wrote:
That's your code, no?
From https://svn.kineticode.com/pgtap/tags/rel-0.02/pg_prove
push @command, qw(
--no-psqlrc
--no-align
--tuples-only
--pset pager=
--pset null=[NULL]
--set ON_ERROR_ROLLBACK=1
On Aug 21, 2008, at 13:58, chromatic wrote:
I wonder why anyone wants a test so complex that its diagnostic
requires you
to serialize and deserialize objects and/or nested data structures
to and
from custom TAP producers and consumers, and, if you really need to
do that,
if you should start
On Aug 21, 2008, at 14:48, Andy Armstrong wrote:
There was meant to be a smiley in my response. I was just relieved
it wasn't some debug /I'd/ left lying around - so thanks :)
:-D
Best,
David
On Sep 1, 2008, at 05:17, David Golden wrote:
if (!$dot_version) {
warn "You must install the graphviz package..." and exit 0;
}
That seems…annoying. I'll grant you that you need to be able to
distinguish real failures from dependency failures, but surely there's
a better way, no?
On Sep 1, 2008, at 17:22, Aristotle Pagaltzis wrote:
Ask the maintainers of M::B, EU::MM and M::I to all export a
`halt` function that does just this? That would also provide
a convenient spot in the respective modules’ docs for related
CPAN Testers arcana, so people wouldn’t have to stumble ont
On Sep 2, 2008, at 13:23, chromatic wrote:
I already know that my distributions don't work if you don't install
the
dependencies, or if you use an unsupported version of Perl. You
don't have
to waste anyone's time testing that. What I don't know is if my
distributions work on different ope
Damn you, Warnock!
:-P
D
On Aug 8, 2008, at 12:46, David E. Wheeler wrote:
Howdy,
I've started fiddling with the stdout option to TAP::Harness. It's
nice, although it doesn't capture everything. I mean, I think it
does, but stuff still gets sent to STDOUT, too. The b
On Sep 3, 2008, at 11:22, Ricardo SIGNES wrote:
* "David E. Wheeler" <[EMAIL PROTECTED]> [2008-09-03T13:27:08]
http://cpantesters.perl.org/author/DWHEELER.rss
Now that there's a new maintainer, I should send another email...
Say what? Sorry, I don't follo
On Sep 4, 2008, at 21:42, Andy Lester wrote:
I want nothing in my inbox that I have not explicitly requested.
Yes, for email reports, it'd be nice to subscribe to a "list" of your
own reports -- and to be able to request which reports you want (fail
only, non-pass, all, etc.).
I want to
On Sep 4, 2008, at 01:19, Eric Wilhelm wrote:
But with the per-tester direct mail, the recipient is powerless to
stop
it, and feeling powerless tends to make people angry.
This, to me, demonstrates better than most points how CPAN Testers is
being crushed by its own success. A few years ag
On Sep 4, 2008, at 10:09, chromatic wrote:
My job is editor, not programmer. Also novelist -- but again, not
programmer.
Certainly not CPAN programmer.
What's your novel? Can I read it?
Paying attention is not my job. Releasing software I've written
under a free
and open license does no
On Sep 4, 2008, at 10:50, David Cantrell wrote:
Change the record, please. This one's getting boring.
Maybe I should start being equally loud and obnoxious about obviously
stupid and broken things like the existence of UNIVERSAL-isa. It
might
give you some appreciation for how you're comin
On Sep 4, 2008, at 13:32, chromatic wrote:
... but my concern is that no matter how well I document the idea
that if
T::MO and T::MO::E appear not to work correctly and that there may be
method-as-function bugs causing the problem, I'll again get a flurry
of bug
reports that I'll have to shu
On Sep 4, 2008, at 15:21, David Cantrell wrote:
What I'm not willing to do, however, is to manually check every report
and ensure perfection that way. Why? Because it takes too long,
and I
have a job and a life.
How about checking a random sample of them, just as a sanity check for
your
On Sep 4, 2008, at 11:53, Andy Lester wrote:
Maybe what's so frustrating to me, and perhaps to chromatic, and
whoever else ignores CPAN Testers but doesn't discuss it, is that
we're being fed things that we should be thankful for and goddammit
why aren't we appreciative??!?
"Here are the
On Sep 5, 2008, at 09:10, Andy Lester wrote:
I'd hate to lose those in my email because other people don't want to
filter their mail.
I'd hate to get spammed because other people don't want to sign up to
receive them.
I think that adding changing things so that authors opt-in to getting
re
On Sep 5, 2008, at 09:13, Andy Lester wrote:
"Here are test reports reporting on failures for these things that
we care about you caring about."
Again, this is CPANTS, not CPAN Testers.
Getting failure reports for a module not running on Perl 5.005 is a
test
about something I don't care a
On Sep 5, 2008, at 09:34, Andy Lester wrote:
Well, yeah, I have too. And sometimes I make a tweak to get things
working on 5.005, and other times I tell my users that it runs 5.006
or later by saying so in Build.PL. Seems reasonable to me to specify
such dependencies.
"Seems reasonable to me"
On Sep 5, 2008, at 10:32, chromatic wrote:
You're right, there's no "compel". If reports don't come by email
to people
who haven't asked for them, then they'll only get reported via an
RSS feed I
can choose to read or not, and on the search.cpan.org pages of my
distributions, which I don't
On Sep 5, 2008, at 10:46, chromatic wrote:
I don't like the check testers/grumble/upload new distribution with no
functional changes just niggly little packaging bits you hope will
opt out of
testers tests you don't care about/sleep/repeat cycle. It's a slow,
clunky
black box game where the
On Sep 5, 2008, at 11:27, Andy Lester wrote:
On Sep 5, 2008, at 12:24 PM, David E. Wheeler wrote:
Punishing? Punishing would be removing a module from CPAN. Getting
fail report emails is annoying and should be changed to be opt-in.
Would that solve your problem?
One person's &quo
On Sep 5, 2008, at 10:57, chromatic wrote:
Full credit (and many thanks) to David Golden and others who are
moving away
from this model, but if I'm an ass for saying "You know, that has a
lot in
common with spam" and "CPAN-related services with good intentions
should
carefully consider the
On Sep 5, 2008, at 11:28, Andy Lester wrote:
Getting fail report emails is annoying and should be changed to be
opt-in. Would that solve your problem?
Oh, and yes. Once we stop spamming people, CPAN Testers then
becomes the Consumer Reports model, not the police model.
Thank you. I think
On Sep 5, 2008, at 11:36, chromatic wrote:
They are annoying, but I'm not sure it's my biggest complaint.
There's also
the arbitrariness of the upload/debug/revise cycle of trying to
please a
black box full of testers. I'm not willing to say that this is
primarily the
fault of CPAN Teste
On Sep 5, 2008, at 12:08, David Golden wrote:
There is sufficient outrage now over email volumes that waiting for
the preference system seems pointless and hopefully, in exchange for
quick action now, those that are most annoyed will be willing to be
patient during the transition from opt-out to
On Sep 5, 2008, at 18:17, chromatic wrote:
Hm. What's your thought on turning that into something which a
Module::Build
or ExtUtils::MakeMaker plugin could run on ./Build distcheck or make
distcheck?
I'm happy to write the Module::Build plugin, if anyone else might
find this
idea useful.
On Sep 6, 2008, at 00:00, Barbie wrote:
The patch that David Wheeler has written for an RSS feed for no PASSes
has already been included into the new report site. The launch of the
site has been put on hold, while I sort out the new mailer. Further
RSS
may become available after the current r
On Sep 6, 2008, at 15:47, Michael G Schwern wrote:
* Changed the message for extra tests run to show the number of
tests run
rather than the number extra to avoid the user having to do
mental math.
[rt.cpan.org 7022]
Smart. I've updated Test.Simple and pgTAP with this change,
On Sep 8, 2008, at 03:49, Ovid wrote:
In the developer release of Test::Simple, Test::Builder has been
altered to die if you have any arguments after 'no_plan'. This
means that some previously passing tests will fail. In fact, there
are two test programs in Moose 0.57 which have this and
On Sep 10, 2008, at 10:30, Eric Wilhelm wrote:
Yes. Please let's not start cutting the ends off of the ham just so
we
can get mom's old pan out of the attic.
Why is there a ham in the pot in the attic? Must be a bit rotten.
Best,
David
On Sep 11, 2008, at 05:09, Andy Armstrong wrote:
On 8 Aug 2008, at 20:46, David E. Wheeler wrote:
I've started fiddling with the stdout option to TAP::Harness. It's
nice, although it doesn't capture everything. I mean, I think it
does, but stuff still gets sent to STDOUT, to
On Sep 11, 2008, at 10:47, Andy Armstrong wrote:
According to svn blame:
470 andy sub summary {
481 andy my ( $self, $aggregate ) = @_;
791 andy
754 andy return if $self->silent;
So I'd say the summary it's been there for a while :)
(we're currently up
On Sep 11, 2008, at 14:17, Michael G Schwern wrote:
Because they all come in at one lump, I have to deal with them in
one lump.
There's no easy system to tell which ones I've dealt with
(previously I'd just
delete the mail) and which ones I haven't.
The way it looks right now, I want my CC'
On Sep 11, 2008, at 15:18, Michael G Schwern wrote:
There also doesn't appear to be a way to get just the failures so I
have to
figure out how to twiddle my RSS reader to filter out the passes.
Barbie says he's worked in a patch from me that will allow you to
subscribe to a feed with only
On Sep 17, 2008, at 13:24, Michael G Schwern wrote:
FWIW I added a TAP column to the Perl section on Wikipedia's list of
unit
testing frameworks. If every testing framework has to sound off on
xUnit, why
not TAP?
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Perl
I think th
On Sep 17, 2008, at 17:51, Michael G Schwern wrote:
I think that you can add TAP columns for JavaScript and PHP, too, no?
Yeah, and so can you. :P
Someone beat me to it for PHP, but I added a TAP column for
JavaScript, along with a link to Test.Simple.
Now if only we could get OpenJSAN a
Howdy,
I've released a new version of pgTAP, 0.10. Grab it here:
http://pgfoundry.org/frs/?group_id=1000389
Changes mainly include lots of new functions for testing a schema
(has_table(), has_view(), has_col(), has_pk(), has_fk(), col_is_pk(),
col_is_fk(), fk_ok(), etc.) and portability a
On Sep 18, 2008, at 16:12, David E. Wheeler wrote:
Howdy,
I've released a new version of pgTAP, 0.10. Grab it here:
http://pgfoundry.org/frs/?group_id=1000389
Changes mainly include lots of new functions for testing a schema
(has_table(), has_view(), has_col(), has_pk(), h
On Sep 20, 2008, at 00:29, Barbie wrote:
See http://use.perl.org/~barbie/journal/37496 for all the gory
details.
Barbie++ # Thank you!
David
On Oct 28, 2008, at 05:29, Ovid wrote:
Just a quick cultural point: over here in the UK, "cunts" is a very
common term and while insulting, is nowhere near the "OH MY GOD WHAT
DID HE JUST SAY?" level of unacceptability in the US. Since many
reading this list are in the US, they might have
On Dec 8, 2008, at 3:30 PM, Barbie wrote:
The latest in the family of CPAN Testers websites has been officially
launched today. The CPAN Testers Preferences Administration website is
for authors to determine their own preferences for the CPAN Testers
reports and summaries.
https://prefs.cpantes
On Dec 12, 2008, at 3:41 AM, Eric Wilhelm wrote:
I've just committed (svn r12149) David Wheeler's change to enable
check
subroutines on properties in Module::Build, which is now used to
validate the installdirs property.
Ah, great. Looks like you committed it as submitted, yes? Did you
cha
On Jan 21, 2009, at 10:47 AM, Ovid wrote:
However, that's going to break if $count is a string, right?
Thought this might work as a heuristic for that third definition:
# Won't get called unless the string has a non-digit in it
multisub skip( Str $desc where { $desc ~~ /\D/ } );
Thus, you
On Jan 21, 2009, at 2:13 PM, Ovid wrote:
... is because we want a default value of 1 for the number of tests
to skip. Eliminate that default and the entire problem goes away.
You must *always* specify the number of tests to skip. $reason is
optional.
Sound good?
Yes, but can the numbe
On Jan 22, 2009, at 11:06 AM, Eric Wilhelm wrote:
That still doesn't imply that we can't somehow count the number of
tests
with a computer instead of relying on humans to screw it up. If some
combination of static analysis and early runtime can come up with a
count, then it becomes possible t
On Jan 22, 2009, at 1:08 PM, Fergal Daly wrote:
Assuming the static analysis was correct, it would always produce the
correct number thus would be equivalent to no_plan. For me, the
purpose of the plan is not to detect failures that cause early exits -
it can do that but the test harness also lo
On Jan 22, 2009, at 2:24 PM, Eric Wilhelm wrote:
Or thereabouts. The business of skipping, todoing, counting,
planning,
and ensuring that all tests actually run is going to involve various
details and possibly even get into the limitations of TAP -- but you
now have every chunk of tests setup
On Jan 22, 2009, at 5:22 PM, Michael G Schwern wrote:
Because, in Perl and other languages, until you run it you can't
know what
class $object is going to be, or what its inheritance tree will look
like, and
once you do figure out which run_tests() will run (if any) you're
back to the
prob
On Jan 22, 2009, at 7:04 PM, Andy Lester wrote:
Please, can we stop going over plans again?
Every minute spent yapping about whether plans are good or not is a
minute that could be spent doing something useful, like working on
Test.pm for Perl 6.
You're going to have to be a bit tolerant
On Jan 22, 2009, at 10:02 PM, Andy Lester wrote:
On Jan 22, 2009, at 11:23 PM, David E. Wheeler wrote:
people see Perl 6 as an opportunity to rethink things.
Except that Perl 6 isn't changing TAP.
No, but there really wasn't any talk about changing TAP in that
thread. It w
On Jan 22, 2009, at 11:22 PM, Ovid wrote:
Well, since the thread was about Eric's method of eliminating
'plan', after you made your explanation, I think it was clear that
the proposal would require, as Eric suggested, an alteration to core
TAP:
ok 1
ok 2
ok 1
ok 2
ok 3
On Jan 23, 2009, at 1:11 AM, Eric Wilhelm wrote:
If so, you're using the plan as something like a stand-in for the
assertion:
my @resources = $manager->resources;
is(scalar(@resources), 12, "have 12 resources");
And actually, you probably want to assert something like:
my @resources = $man
On Jan 23, 2009, at 10:18 AM, Fergal Daly wrote:
With nesting, you can move some aspects of the plan closer to the code
(which is good) but you must always have some part of the plan far
enough away from the code so that it is not subject to the same bugs.
Ideally something like this would work
On Jan 23, 2009, at 10:23 AM, Eric Wilhelm wrote:
I don't recall claiming that it was *simpler*. The single static
numeric plan is simplistic. Given any cross-platform skip issue or
optional-dependency condition, you have a situation where the plan
becomes harder for a human to get right. In
On Jan 23, 2009, at 11:25 PM, Michael G Schwern wrote:
I don't cut off and discard the ends of roasts, either.
You would if you were still using the same pot your grandma was
using, which
we mostly are.
Dude, does your grandma deal? Sounds like really good stuff.
David
Howdy,
This is for Any Armstrong, primarily, but someone else might know the
answer, or be interested, anyway.
I added xUnit-style test programming to pgTAP recently. What this
means is that, rather than putting tests in a .sql test file, a
developer can define a function that returns the
On Feb 4, 2009, at 6:35 AM, Ovid wrote:
Thoughts?
(The first idea is bugging me because I swear I had thought of a
show-stopper over lunch, but for the life of me, I can't recall what
it was).
Must've been a damn good lunch. How many pints did you kill?
D
On Feb 4, 2009, at 3:15 PM, Ovid wrote:
Only one. The BBC frowns on it if you come back *completely*
wasted. I'd probably get a stern talking to if I did.
Ooh, scary.
D
On Feb 5, 2009, at 12:34 PM, Michael G Schwern wrote:
Though we don't have incremental TAP plans, Test::Builder can check
that
you've run all the tests you said you'd run before you add more.
Thus...
use Test::More;
plan add => 2;
pass;
plan add => 1;
pass; # failure
pass
1 - 100 of 156 matches
Mail list logo
