I've been chatting with Casey about how we should best be dealing with
the perlbug RT interface - e.g. what to do when you come across a bug
that's resolved, what the various statuses mean etc.
There doesn't seem to be any documentation anywhere on this, and we
thought the QA wiki might be a usef
What's the current approach to turning perlbugs into tests?
Should they be done as TODOs? Is there a distinct set of test files for
them? etc? Can they use Test::More? etc. etc. etc.
e.g. http://bugs6.perl.org/rt2/Ticket/Display.html?id=5430
can have a fairly simple test like:
package
On Fri, Jul 18, 2003 at 01:54:24PM -0700, chromatic wrote:
> In general, the person who fixes the bug writes a regression test for
> the bug. The pumpkings and other porters are really good about making
> sure patches have tests.
Yes, but I'm talking about outstanding bugs that don't have tests
On Thu, Jul 24, 2003 at 09:17:02AM -0400, Potozniak, Andrew wrote:
> &Test::More::is(1,1,"One equals One!!");
> &Test::More::is(1,2,"Does one equal two??");
You probably don't want to be calling those with the & in front of them
either as that'll make them bypass the prototype.
And as the Test fu
>From Test::More docs:
# XXX BAD! $pope->isa('Catholic') eq 1
is( $pope->isa('Catholic'), 1,'Is the Pope Catholic?' );
This does not check if "$pope-"isa('Catholic')> is
true, it checks if it returns 1. Very different.
Similar
Has anyone added a "./Build cover" target for Module::Build yet? I'm
trying to move some of my stuff from MakeMaker to Build, and can't
really work out how to pull my "make cover" equivalent across...
Thanks,
Tony
On Thu, Jul 31, 2003 at 11:47:41AM +0100, Richard Clamp wrote:
> > trying to move some of my stuff from MakeMaker to Build, and can't
> > really work out how to pull my "make cover" equivalent across...
> From Siesta::Build, Siesta's Module::Build subclass:
> sub ACTION_cover {
> my $self = shi
On Mon, Aug 18, 2003 at 08:13:58PM -0500, Ed Summers wrote:
> > Upload a dist and let it be checked by a future version of Module::CPANTS.
> That's actually kind of a neat idea. It makes me think how cool it would be if
> Module::CPANTS installed a script which would do the same thing...from the
>
On Tue, Aug 19, 2003 at 02:29:30PM +0100, Adrian Howard wrote:
> >In _Software Craftsmanship_, Pete McBreen has high praise for:
> > The Craft of Software Testing
> >It's out of print and nearly impossible to find. I haven't read it
> >yet, so I can't say whether it is as seminal as McBreen s
#!/usr/bin/perl -w
use Test::More tests => 1;
eval { die "Foo" };
ok $@, \$@;
...
1..1
Invalid value for shared scalar at /usr/local/share/perl/5.8.0/Test/Builder.pm line
319.
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the auth
On Mon, Aug 18, 2003 at 10:11:23PM +1000, Iain Truskett wrote:
> > Sure, convince CPAN Testers to do this ;-)
> I've been playing with Devel::Cover and think this is a good
> idea. But damned if I know how to report the Devel::Cover
> output in a useful way in an email.
You can write your own repo
I was having a look at CPANTS again this morning, and I noticed
something rather strange.
There are now two kwalitee tests for 'has_test_pod' and
'has_test_pod_coverage'. These check that there are test scripts for
POD correctness and POD coverage.
These seem completely and utterly wrong to me.
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote:
> Anyway, I invite everybody to suggest new metrics
I'd like the "is pre-req" thing to be more useful. Rather than a binary
yes/no thing (and the abuses it leads to), I'd rather have something
akin to Google's Page Rank, where the s
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote:
> > We should be very wary of stipulating HOW authors have to achieve their
> > quality. Saying you can only check your POD in one specific way goes to
> > far IMO.
> That's a good point.
> OTOH, I know of several people who added Pod
On Thu, Apr 07, 2005 at 08:56:26AM -0400, Christopher H. Laco wrote:
> I would go as for to say that checking the authors development
> intentions via checks like Test::Pod::Coverage, Test::Strict,
> Test::Distribution, etc is just as important, if not more, than just
> checkong syntax and that
On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote:
> >CPANTS can't check that for me, as I don't ship those tests.
> >They're part of my development environment, not part of my release tree.
> That is true. But if you don't ship them, how do I know you bothered to
> check those t
On Thu, Apr 07, 2005 at 02:34:21PM -0400, David Golden wrote:
> * Shipping tests is a hint that a developer at least thought about
> testing. Counter: It's no guarantee of the quality of testing and can
> be easily spoofed to raise quality.
This is certainly not why I ship tests, and I've never
On Sun, Apr 17, 2005 at 08:24:01AM +, Smylers wrote:
> Negative quality for anybody who includes a literal tab character
> anywhere in the distro's source!
Negative quality for anyone whose files appear to have been edited in
emacs!
Tony
On Sun, Apr 17, 2005 at 12:17:17AM +, Smylers wrote:
> Remember that we aren't measuring quality, but kwalitee. Kwalitee is
> supposed to provide a reasonable indication of quality, so far as that's
> possible. So what matters in determining whether a kwalitee heuristic
> is appropriate is wh
Is there any simple way to remove the test files themselves from the
Devel::Cover results? i.e. just see the coverage analysis of the files
being tested rather than all the t/* files as well?
We want to monitor the total coverage over time on a project, and it
would be nice to just grab that from
On Thu, Jun 24, 2004 at 02:59:30PM -0400, Andrew Pimlott wrote:
> I see this more as a limitation than a feature. It seems to mean that
> - You need to use the same setup/teardown for all your tests.
Those that need different things aren't testing the same thing and
should move to a different cla
On Thu, Jun 24, 2004 at 07:13:08PM -0400, Andrew Pimlott wrote:
> But (I thought) the idea was that every test needs the same setup. If
> they're all in one method, they won't get that.
How's that?
> Also, if you add lots of tests in a single method, (again as I understand)
> they will stop a
On Fri, Jun 25, 2004 at 11:10:19AM -0400, Andrew Pimlott wrote:
> I thought the "isolation" principle that people were talking about is
> that before every test, a "setup" method is called, and after every test
> a "teardown" is called, automatically by the test harness. This
> seems to require on
On Fri, Jun 25, 2004 at 01:07:36PM -0400, Andrew Pimlott wrote:
> You are also circumventing the isolation part of the xUnit model,
> because you don't get setup/teardown for each test data. Possibly you
> don't care about that in this case, but if you did, you wouldn't be able
> to do the above,
On Sun, Jul 11, 2004 at 12:46:01AM -0400, Michael G Schwern wrote:
> Most modules now have a META.yml file which contains (amongst other things)
> module dependency information. Simplest thing to do would be to make a
> local miniCPAN mirror [1] and walk through the archive files [2] in
> modules
We have an in-house procedure that says that the SQL definition for a
table should be included in the __DATA__ section of the class that
represents it (we're using Class::DBI), and is to be treated as the
definitive version of the schema.
When the code gets deployed to a new server, we'd like to
On Mon, Jul 19, 2004 at 03:22:05AM -0400, Michael G Schwern wrote:
> > The two "best" ideas we've had so far are to either run the SQL in the
> > code against a temporary database, and then compare both SHOW CREATE
> > TABLE outputs, or to use something like SQL::Translator to convert both
> > lots
On Sun, Jul 18, 2004 at 04:49:24PM +0200, James Mastros wrote:
> Change the procedure to require the bit after __DATA__ to match what
> mysql gives you back? This is actually better then what you do anyway,
> as what mysql gives you is significantly more detailed.
We considered that, but, among
On Fri, Jul 23, 2004 at 08:41:58AM +0200, James Mastros wrote:
> BTW, I tend to think that modules that require lots of other things
> deserve lower kwalitee...
Because reinventing the wheel is a good thing, right?
Tony
On Thu, Aug 05, 2004 at 11:51:09PM -0500, Andy Lester wrote:
> It'd be swell if someone generated Devel::Cover dumps for the
> Phalanx 100. Like http://pjcj.sytes.net/cpancover/ but for
> http://qa.perl.org/phalanx/distros.html.
It would be nice if anyone doing the Class::DBI one made sure that t
On Tue, Aug 17, 2004 at 04:21:09PM +, [EMAIL PROTECTED] wrote:
> No. There's (currently) no option for doing so. The HTML is well formed,
> though, which should make building a filter easy if you know how the
> formatting works. ;) e.g.:
Or applying an XSLT file to it?
Tony
There's been a protracted discussion on the code-review mailing list
about the behaviour of is_deeply in Test::More, which really belongs
here or p5p.
For the most part it was sparked by a disagreement about what should
happen when comparing overloaded objects (but also then impacts on tied
objec
On Tue, Sep 09, 2003 at 01:07:00PM +0100, Fergal Daly wrote:
> The question needs changing. Both versions of is_deeply will give the same
> answer on these tests.
But do you agree that they should all pass?
If so I've completely misunderstood your earlier arguments. They certainly
aren't "deepl
On Tue, Sep 09, 2003 at 01:25:22PM +0100, Adrian Howard wrote:
> >1) ok $str1 eq $str2;
> >2) is $str1, $str2;
> >3) is_deeply [$str1], [$str2];
> >4) is_deeply $str1, $str2;
> All should pass as far as I am concerned.
OK - what if it was slightly more complex:
package MyString;
use overload
On Tue, Sep 09, 2003 at 05:49:47PM +0100, Fergal Daly wrote:
> > my $str1 = MyString->new("foo", "bar");
> > my $str2 = MyOtherString->new("foo", "baz");
>
> Now they _do_ differ by more than just class and it should be a fail, although
> I must admit that even with the current is_deeply it will
On Tue, Sep 09, 2003 at 06:09:16PM +0100, Fergal Daly wrote:
> But it doesn't fail, it never has failed and it was never intended to fail.
> is_deeply is specifically for looking at and descending into the structure of
> it's arguments, otherwise what's the point? Where's the "deep"ness?
I don't
On Tue, Sep 09, 2003 at 08:50:06PM +0100, Fergal Daly wrote:
> The docs for is() says it uses eq, is_deeply() says it looks inside, it
> doesn't say "looks inside sometimes".
It says it looks inside listrefs and hashrefs. That's all.
Objects are not listrefs and hashrefs. They are sometimes mad
On Wed, Sep 10, 2003 at 07:18:53AM -0400, [EMAIL PROTECTED] wrote:
> > The fact the is_deeply currently looks inside them is a bug.
> The AUTHOR INTENDED IT TO and so it is not a bug.
The author's intent is entirely irrelevant to whether or not something
is a bug.
> and you want to ignore Michae
On Sun, Oct 12, 2003 at 01:08:39PM +, Mark Stosberg wrote:
> A second sticking point could be that code is OS-specific, so it's not ever going
> to get testing by just one build machine.
And also, in the case of things like Class::DBI, have database specific
code in them, that is tested, but c
On Mon, Oct 20, 2003 at 08:34:50AM -0700, Ovid wrote:
> the suite of 15,000 tests takes about an hour to run.
Devel::Cover issues aside, has anyone else looked at interesting ways of
making test suites run faster?
We insist on a full regression test on checkin, so having the test suite
take a lon
On Mon, Oct 20, 2003 at 10:25:17AM -0700, Bob Goolsby (bogoolsb) wrote:
> There is another side to the "made-up" data issue. There are instances
> where you legally can _not_ use live data. Consider a Hospital or
> Insurance company, for example ...
In Europe it's pretty much illegal for any c
On Mon, Oct 20, 2003 at 12:10:33PM -0500, Andy Lester wrote:
> One of the drums I beat heavily in my discussion of testing of large
> projects is that you shouldn't care how long your tests take, so long as
> they run within the smokebot window.
This doesn't work so well with aegis, which has a me
On Mon, Oct 20, 2003 at 10:47:02AM -0700, Ovid wrote:
> The way we're doing tests is simply foolish and we could experience some significant
> productivity
> gains if we were to improve the test performance. Of course, I think it's fair to
> point out that
> much of the performance is due to a p
On Mon, Oct 20, 2003 at 07:02:56PM +, [EMAIL PROTECTED] wrote:
> Practically, the only way to do this is to save the results of each test
> in a seperate cover_db and then selectively merge them to see whether or
> not your coverage changed. Even then, finding the minimal set of tests
> that
On Mon, Oct 20, 2003 at 10:16:40PM +0200, Paul Johnson wrote:
> I wrote "database" in quotes because currently we are talking about a
> flat file, written using Data::Dumper and eval'd in. I have considered
> other options - specifically YAML and Storable. I have found YAML to be
> even slower an
In one of my local applications, the regression test has just started to
fail with:
dubious
Test returned status 0 (wstat 14, 0xe)
Constant subroutine __need_size_t redefined at
/usr/lib/perl/5.8.0/stddef.ph line 147.
after all the subtests completed successfully
Bizarrely this only happens
On Tue, Oct 28, 2003 at 07:36:03PM -0600, Michael Carman wrote:
> > It is still huge ~870K but I could not find any easy way to remove further
> > large chunks without changing the resulting page.
> You won't find any more low hanging fruit. There's a lot of markup in building
> that table, so it's
On Mon, Nov 03, 2003 at 02:06:01PM +, Tim Bunce wrote:
> A separate issue with C is that code using it generally assumes
> that the has itterator is at the start of the hash. If it's not
> (because an C loop somewhere terminated early, for example)
> then some items of the hash will be skipped.
On Tue, Jan 27, 2004 at 10:37:48AM -0500, Potozniak, Andrew wrote:
> To make a long story short I can not get access to the source of the bottom
> frame through JavaScript because of an access denied error. Has anyone else
> ran into this problem or does anyone know of a solution to this problem?
On Tue, Feb 10, 2004 at 06:41:00PM -0800, Michael G Schwern wrote:
> Trouble is, I haven't used Aegis since 2001 and never in such a distributed
> environment and never played with aedist or maintained the repository.
> So I could use some help. At this point I'd just like to know who out
> there
50 matches
Mail list logo
