[Dancer-users] Writing tests for Dancer::Plugins

sawyer x xsawyerx at gmail.com
Wed Aug 3 09:52:07 CEST 2011

Hey Colin!

On Wed, Aug 3, 2011 at 8:06 AM, Colin Keith <colinmkeith at gmail.com> wrote:

> Hi,
> I'm a newbie to Dancer but so far I like a lot of what I see.

Happy to hear you're enjoying yourself. :)

> More specifically I just finished writing a plugin for Dancer but
> being a plugin I'm not sure how to write the tests. What is considered
> the best way to approach testing them, whip up a quick dancer app in a
> test file?

Dancer::Test has some shortcomings that made us decide to rewrite it.
However, we haven't reached that time yet.
We find it useful to use Test::TCP to start a server instance with Dancer,
then testing against it. I'm personally still partial to

Feel free to go over our test directory (which is sorted by subjects) to get
some impressions of how we find it comfortable to test Dancer.

A scaffolding instance of Dancer also includes some tests, to get an
understanding of how writing with Dancer::Test looks like.

> Also, since I'm asking for best practice info;
> 1. Is it considered better to release to Github and then to CPAN per
> Dancer itself?

Usually it's more comfortable for the developer to put a project on Github
before releasing it to CPAN, because then you can get feedback from the
community and you get a commit history (via git) sooner. There is at least
one plugin of which I know that isn't on Github at all, or on any revision
control management. Not mine of course. :)

This is completely up to you.

> 2. Are there any guidelines on the naming of Dancer plugins

Yes, though not a lot.
* Basically plugins go into the Dancer::Plugin:: namespace.
* Try not to pick a namespace that is too generic. We want users to be able
to share namespaces when their plugins are related. For example:
Dancer::Plugin::Auth::ThisMethod, Dancer::Plugin::Auth::ThatMethod.
* When in doubt, simply ask us. :)

> 3. Does any one have any good refs for writing unit tests. Most things
> I've read so far only say how great their  (yet another) Test::*
> module is, cover the basic stuff over and over. I know how to write
> the tests, I'm trying to determine what is considered a good level of
> writing tests.

The best way is to take a modern project and check out how it writes tests.
I use Test::More for most things, Test::Fatal for exception checks,
Test::TinyMocker (which we actually wrote as part of Dancer but released
separately due to popular demand) for mocking objects.

I generally write unit tests. If there's something complicated, I'll write a
point-to-point (overall) test and then later break it down to unit tests.
Writing in unit tests just helps me understand my code better, notice when
and where to refactor it and how the user will use it.

My rule of thumb with refactoring is: "if I have to jump through hoops to
test this method instead of mocking a few methods (at most), it's too
complicated and needs refactoring" - this usually leads me to healthy
well-tested code. A few of my modules even reach 100% coverage (not that
it's the best metrics).

Hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110803/b0841b88/attachment.htm>

More information about the Dancer-users mailing list