Generally I use a mix of stuff.  I use Test::DBIx::Class for database domain 
logic testing, and some of the psgi and mechanize test stuff for testing http 
interaction.  When I have a stand alone class, I typically use Test::Most

In the past I used Test::Class and I found that it tends to be more complicated 
than I really need (I had test cases for my subclasses of Test::Class :)) But 
some people do use it and are happy.

When using Test::DBIx::Class or Test::WWW::Mechanize::Catalyst and the related 
PSGI testing stuff, I tend now to use the testing helper stuff built into 
DBIx::Class::Migration (is covered in the tutorial for DBIC:Migration).

Of course that's my stack and I wrote Test::DBIx::Class and DBIC:M so that's 
not going to be a big surprise to anyone I imagine!

Lately I try to think about the long term health of my test cases, so that its 
more clear to link a test to a user requirement, feature or bug report.  I've 
been playing with behavior driven development, Cucumber and similar, but I know 
that's a lot of koolaide for some people to drink.  I just think lately that 
often we have this opaque test cases that people really can't understand, and 
it would be nice to be able to link the test case to some sort of statement.  I 
guess documentation in the test cases would also help.



> From: Bill Moseley <>
>To: The elegant MVC web framework <> 
>Sent: Sunday, September 30, 2012 12:12 PM
>Subject: [Catalyst] Better Testing
>Anyone using Test::Sweet or Test::Class(::Most) with your large Catalyst apps? 
>  Opinions about either -- or lessons learned?  Anything else to look at?
>We have tended to write pretty standard procedural-style tests which are easy 
>to understand across our team (for a few dozen developers) and often end up 
>factoring out common code into utility classes.  But, those utility classes 
>are often one-offs and at the whim of the developer how to structure it.   I 
>do want something more standardized but easily extensible.
>I'm finding Test::Class works great for unit tests -- especially when testing 
>related sub-classes -- but we tend to write more feature/integration tests.   
>In other words, tests are longer and depend on previous tests.   I guess 
>another term might be workflow tests.
>I want a framework that enforces good structure, and also that makes it easy 
>to run single tests (that is, run a single tests within a single .t file) to 
>make debugging faster.  (e.g. Run the first five tests of 20.)
>On the other side, and perhaps unrelated to above, but I do want to make sure 
>our tests can be run in parallel so we can run full-test more often and take 
>advantage of our larger multi-core machines.
>Bill Moseley
>Searchable archive:
>Dev site:
Searchable archive:
Dev site:

Reply via email to