[Catalyst] Better Testing

[John Napiorkowski]

Bill,

Generally I use a mix of stuff. =A0I use Test::DBIx::Class for database dom=
ain logic testing, and some of the psgi and mechanize test stuff for testin=
g http interaction. =A0When I have a stand alone class, I typically use Tes=
t::Most

In the past I used Test::Class and I found that it tends to be more complic=
ated 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=A0Test::WWW::Mechanize::Catalyst and the re=
lated 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.=
 =A0I've been playing with behavior driven development, Cucumber and simila=
r, but I know that's a lot of koolaide for some people to drink. =A0I just =
think lately that often we have this opaque test cases that people really c=
an't understand, and it would be nice to be able to link the test case to s=
ome sort of statement. =A0I guess documentation in the test cases would als=
o help.

goodluck!

John



>________________________________
> From: Bill Moseley <moseley at hank.org>
>To: The elegant MVC web framework <catalyst at lists.scsys.co.uk> =

>Sent: Sunday, September 30, 2012 12:12 PM
>Subject: [Catalyst] Better Testing
> =

>
>Anyone using Test::Sweet or Test::Class(::Most) with your large Catalyst a=
pps? =A0 Opinions about either -- or lessons learned? =A0Anything else to l=
ook at?
>
>
>We have tended to write pretty standard procedural-style tests which are e=
asy to understand across our team (for a few dozen developers) and often en=
d up factoring out common code into utility classes. =A0But, those utility =
classes are often one-offs and at the whim of the developer how to structur=
e it. =A0 I do want something more standardized but easily extensible.
>
>
>I'm finding Test::Class works great for unit tests -- especially when test=
ing related sub-classes -- but we tend to write more feature/integration te=
sts. =A0 In other words, tests are longer and depend on previous tests. =A0=
 I guess another term might be workflow tests.
>
>
>I want a framework that enforces good structure, and also that makes it ea=
sy to run single tests (that is, run a single tests within a single .t file=
) to make debugging faster. =A0(e.g. Run the first five tests of 20.)
>
>
>On the other side, and perhaps unrelated to above, but I do want to make s=
ure 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
>moseley at hank.org
>
>_______________________________________________
>List: Catalyst at lists.scsys.co.uk
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>Dev site: http://dev.catalyst.perl.org/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20121002/b72dd=
49e/attachment.htm