On Thu, Mar 26, 2009 at 10:46 AM, Ovid wrote:
> For those of you in large environments, do you run "make test" or an
> equivalent when you push your code out to a production server? Why or why
> not?
For our more mature product, we absolutely run "make test" prior to
production push, even thou
First, in the notes comes this: 'this report is from an automated smoke
testing program and was not reviewed by a human for accuracy'. Thus, the
"you" is completely inappropriate. The bot may have not installed it, but
then again, it may not had to, because *a* module called Template may have
alrea
First, in the notes comes this: 'this report is from an automated smoke
testing program and was not reviewed by a human for accuracy'. Thus, the
"you" is completely inappropriate. The bot may have not installed it, but
then again, it may not had to, because *a* module called Template may have
alrea
ok at
<http://qa.perl.org> and the Test::Tutorial module, on the web at
<http://search.cpan.org/~mschwern/Test-Simple-0.67/lib/Test/Tutorial.pod>.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
.
I used PBP because I know you're familiar with it, due to your release of
Carp::Diagnostics. My point was that having coding standards is one
thing; asking other people to remove their code to meet standards you have
is another entirely.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
de standards to meet, and that's
to be expected. Be sure to update yours to the things you've mentioned.
TIMTOWTDI rules here, though, and PBP isn't a rulebook - it's a set of
guidelines that work for Damian. Other people use them to varying
degrees, and P::C even implements them, but at some point, people are on
their own.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
iciency, unless
efficiency is what you're testing. They should be about correctness, then
completeness, then efficiency after that.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
Subject: TAP 2.0
From: Ovid <[EMAIL PROTECTED]>
Date: Fri, 29 Sep 2006 16:00:22 -0700 (PDT)
}got: <
"u" is interpreted as the maximal
number of bytes to encode per line of output, with 0
and 1 replaced by 45.
So it's only packing the first element of the list.
Even if you changed the pack to "uu", since two uuencoded strings
c
The repeat count for "u" is interpreted as the maximal
number of bytes to encode per line of output, with 0
and 1 replaced by 45.
So it's only packing the first element of the list.
Even if you changed the pack to "uu&quo
t would raw-test
show for this?
is($user,"testuser$id","Test user name correctly generated");
-Pete K
--
Pete Krawczyk
perl at bsod dot net
smarter
people than I in contract law have worked it out before me, and I'm
intelligent enough to trust their judgements.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
e_condition;
plan tests => 22;
skip_all is a plan descriptor and as such needs to be given to plan.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
ou post an example? The logical spot for having the module
}"phone home" would be in the Makefile.PL. I also glanced at some tests,
}but didn't see anything there, either.
Look in the Build.PL, which Makefile.PL also calls.
http://search.cpan.org/src/NICOLAW/WWW-Dilbert-1.19/B
quot;$class->can(...)" );
$tb->diag('can_ok() called with no methods');
======
The patch does not address a method name that is undefined.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
t away from the block in question.
}Second, if it's not a valid invocant, you need to wrap the whole
}expression in an eval block.
Again, this is already done, but unlike other places (e.g. Scalar::Util)
that run an eval that might die, $SIG{__DIE__} is not localized.
-Pete K
--
Pete Krawczy
lly be the best fix, but I'd rather
not see the incoming object have a method called if it's not even blessed.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
f
going back to 5.4.0.
Stealing the code from Scalar::Util isn't necessarily the best fix either.
Does anyone have a better way of checking whether an object is blessed
that's backportable through core?
-Pete K
--
Pete Krawczyk
perl at bsod dot net
Subject: Re: Test::More behavior issue with Devel::Cover + patch
From: Ricardo SIGNES <[EMAIL PROTECTED]>
Date: Thu, 3 Nov 2005 13:14:34 -0500
}* Pete Krawczyk <[EMAIL PROTECTED]> [2005-11-03T12:46:48]
}>
}> The solution I see is to make sure the object can() isa(), thus avoid
ect, $class) ) {
+my $ref = ref $object;
+$diag = "$obj_name isn't a '$class' it's a '$ref'";
+}
+}
And that makes prove happy once more.
Thanks,
-Pete K
--
Pete Krawczyk
perl at bsod dot net
Subject: prove with Devel::Cover example?
From: Mark Stosberg <[EMAIL PROTECTED]>
Date: Fri, 3 Jun 2005 18:44:53 + (UTC)
}How can I use 'prove' and Devel::Cover together? I tried:
HARNESS_PERL_SWITCHES=-MDevel::Cover prove file.t
-Pete K
--
Pete Krawczyk
perl at bsod dot net
arily public right now, but if I had a hardware-level
test suite that simulated what I was actually doing, I could find out much
quicker if that new stick of RAM I put in my computer was going to cause
unexpected behavior.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
I had written a private module for myself that allows exit() to be changed
on-the-fly so that it could be explicitly changed for shorter periods of
time than "the entire script". I never released it, though.
-Pete K
--
Pete Krawczyk
perl at bsod dot net
ir POD documentation.
I agree completely that documenting private interfaces within a POD doc
will do little to help the average developer who just wants to use the
module, and may in fact wind up causing problems for a module developer
that changes the internal structure of their module in
place in a regular
"make test" run?
-Pete K
--
Pete Krawczyk
perl at bsod dot net
25 matches
Mail list logo
