Hi all,
After much agony, I finally managed to get our test suite running with 5.8.1.
Unfortunately, the
suite of 15,000 tests takes about an hour to run. After it finished, Devel::Cover
proceeded to
use more and more memory until finally someone on our night crew killed the process.
I'm wond
--- Ovid <[EMAIL PROTECTED]> wrote:
> I'm wondering if coverage results are cumulative? If I have tests in four different
> directories ...
Of course they are, if the -merge option is on. I missed that.
You may now return to your regularly scheduled programming.
Whoops,
Ovid
=
Silence i
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 04:07, Andrew Savige wrote:
> I noticed in Test::Tutorial:
> "Taint mode is a funny thing. It's the globalest of all global features.
> Once you turn it on it effects all code in your program and all modules
> used (and all the mo
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
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 18:35, Tony Bowden wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 18:26, Ovid wrote:
> --- Ovid <[EMAIL PROTECTED]> wrote:
> > I'm wondering if coverage results are cumulative? If I have tests in
> > four different directories ...
>
> Of course they are, if the -merge option is on. I missed th
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> We insist on a full regression test on checkin, so having the test suite
> take a long time to run puts people off making small changes. :(
>
> On one project a full regression test takes about 8 minutes, which is at
> least an order of magnitude longer
> Devel::Cover issues aside, has anyone else looked at interesting ways of
> making test suites run faster?
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.
The way we
At 10:00 AM 10/20/2003 -0700, Ovid wrote:
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> We insist on a full regression test on checkin, so having the test suite
> take a long time to run puts people off making small changes. :(
>
> On one project a full regression test takes about 8 minutes, which i
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 19:10, Andy Lester wrote:
> > Devel::Cover issues aside, has anyone else looked at interesting ways of
> > making test suites run faster?
>
> One of the drums I beat heavily in my discussion of testing of large
> projects is that
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
--- Andy Lester <[EMAIL PROTECTED]> 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.
Sorry Andy, I can't quite agree with you on this one. Technically, yo
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
Tony Bowden wrote:
>
> One other interesting idea I had, although I have no idea how
> practical it is at all really, it to have some way of telling from the
> Devel::Cover reports (or otherwise) what tests aren't actually adding
> any value as the stuff they're testing is already adequately te
--- Tels <[EMAIL PROTECTED]> wrote:
> Well, still it would be good to improve the speed of Devel::Cover, on my box
> (lowly 500 Mhz, yes, I could upgrade to 2 Ghz AMD or so :) a particulary
> project takes 33 minutes for one run... not exactly what I call "interactive"
> :)
Frankly, I think some m
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 12:24:14PM -0700, Ovid wrote:
> --- Tels <[EMAIL PROTECTED]> wrote:
> > Well, still it would be good to improve the speed of Devel::Cover,
> > on my box (lowly 500 Mhz, yes, I could upgrade to 2 Ghz AMD or so :)
> > a particulary project takes 33 minutes for one run... not e
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
On Mon, Oct 20, 2003 at 08:41:12PM +0100, Tony Bowden wrote:
> 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 co
Tels wrote:
test. I know I have at least written one that did "setup and compile" some
stuff in test 00, and then runs the rest,
Theres something of a nascent convention here;
00_*.t and 99_*.t could be 'reserved' to be 1st and last
respectively, with others randomized.
begin_* and end_* ar
> Theres something of a nascent convention here;
> 00_*.t and 99_*.t could be 'reserved' to be 1st and last
> respectively, with others randomized.
That's pretty much what I was thinking about doing. [0-4]*.t = startup,
in that order, and [5-9]*.t = shutdown, in that order. The rest are
shuff
On Mon, Oct 20, 2003 at 09:34:38PM +0100, Tony Bowden wrote:
> 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 - spec
--- Paul Johnson <[EMAIL PROTECTED]> wrote:
> Initially I wanted something with few, or better yet no dependencies. I
> also wanted something that required little or no work when I changed the
> internal data structures.
Well, SQLite fails the first and *might* fail on the second. On the other h
On Mon, Oct 20, 2003 at 02:10:51PM -0700, Ovid wrote:
> I'm trying to talk my boss into letting me poke into the internals of
> Devel::Cover more, but I doubt that will be approved. If it is, maybe
> I can work on this.
If you or anyone else does get to look at this the code should all be
locali
On 10/20/2003 2:41 PM, Tony Bowden wrote:
> On Mon, Oct 20, 2003 at 07:02:56PM +, [EMAIL PROTECTED] wrote:
>>
>> If the code has been properly designed (i.e. factored into separate
>> pieces without lots of ugly interdependancies) it should be
>> possible to run the module-level test for that
On Mon, 20 Oct 2003, Andrew Savige wrote:
> I noticed in Test::Tutorial:
> "Taint mode is a funny thing. It's the globalest of all global features.
> Once you turn it on it effects all code in your program and all modules
> used (and all the modules they use). If a single piece of code isn't
> tai
On Tue, Oct 21, 2003 at 12:24:03AM -0500, Dave Rolsky wrote:
> On Mon, 20 Oct 2003, Andrew Savige wrote:
> > I noticed in Test::Tutorial:
> > "Taint mode is a funny thing. It's the globalest of all global features.
> > Once you turn it on it effects all code in your program and all modules
> > used
28 matches
Mail list logo
