Hi,
I spend a rather large amount of time writing and running tests. There are a
few things that could be better. I either don't know how or it may not
possible. I thought we could share some of questions and ideas that can make
working with tests more pleasent. This should go into a Q&A I gue
Hi, This mail is not discussing what quality and what test quality is. It is
about what quality our 'test files' have.
I run Test::Fixme, Kwalitee, perl::Critic, etc ... on my modules but none of
them is ran on my tests. tests have a tendency to become a mess, be
undocumented, etc...
What are
nadim khemir wrote:
> I spend a rather large amount of time writing and running tests. There are a
> few things that could be better. I either don't know how or it may not
> possible. I thought we could share some of questions and ideas that can make
> working with tests more pleasent. This sho
> On Sat, 17 Nov 2007 21:47:57 -0800, Matisse Enzer <[EMAIL PROTECTED]>
> said:
> On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:
>> So in order to make everything work robustly, distros should
>> explicitly list every single module they explicitly use no
>> shortcuts, no implica
On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote:
Even if it's in the perl core, the developer may have compiled with
-Dnoextensions=Encode
In such a case Encode is not present. I have skipped Encode many times
because it takes up so much time, others may do likewise.
So, I think t
On Nov 18, 2007, at 3:50 AM, Michael G Schwern wrote:
I start at the top, read the first few failures, fix them and
rerun. I ignore
the bulk of a really large failure as they're probably just cascades
of the
one mistake.
This reminds me - I was wondering what it would take to implement
On Nov 18, 2007, at 3:50 AM, nadim khemir wrote:
What are your thoughts, way of working that avoid the problems to
start with
I organize my test files using an approach similar to nUnit - I create
a bunch of subroutines that each do a few assertions, and that call
set_up() and tear_down(
This is an announcement that my modules will no longer try to be backwards
compatible with 5.5.x. This includes ExtUtils::MakeMaker and Test::More.
Toolchain modules will now target 5.6.0. Modules not part of the build
toolchain will be moving up to 5.8.0.
This doesn't mean I'm going to go right
