Still working on Test::Aggregate, but so far it works well. Currently we have tests which would normally take 13m25s running in 4m17s. I call that a win.
Regrettably, this might kill Test::Class adoption for us. Test::Class also runs the code in a single process, but the inherited tests push the test time up to an unacceptable level. This is disappointing to me as I would love to convert almost all of our tests over to Test::Class. It's one of the best test modules out there.
I'm curious - why are the inherited tests pushing the test times up? Is it just the OO overhead or am I doing something stupid and slow somewhere?but the inherited tests push the test time up to an unacceptable level
Re:Why the time increase?
Ovid on 2008-06-24T11:41:10
I'm being overly verbose in my answer not because I think you need this, but I assume that most people reading this have never used Test::Class.
It's not your fault at all. The vast majority of time for most test suites I work with is either I/O or the sheer number of tests. Since Test::Class inherits tests (as it should!), then when I run Test::Pips3::Report::Query::Validation::ExceptionsByPeriod, which naturally inherits from Test::Pips3::Report::Query::Validation, I get all non-overridden superclass tests run for my subclass. This is fantastic because it means I didn't accidentally break some functionality I forgot to test, but it's a huge explosion in my test count.
Re:Why the time increase?
Adrian on 2008-06-24T11:50:26
Hmmm... so it might be nice to (optionally) not inherit tests for a particular test run.... Added to the to do list:-)
