Hey Colin!
On Wed, Aug 3, 2011 at 8:06 AM, Colin Keith
<colinmkeith@gmail.com> wrote:
Hi,
I'm a newbie to Dancer but so far I like a lot of what I see.
Welcome!
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 Test::WWW::Mechanize.
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).