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

[David Precious]

On Wednesday 03 August 2011 06:06:07 Colin Keith wrote:
> Hi,
> 
> I'm a newbie to Dancer but so far I like a lot of what I see.

Welcome to the community :)


> 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?

That's basically the approach used for the tests for Dancer::Plugin::Database

https://github.com/bigpresh/Dancer-Plugin-Database/blob/master/t/01-basic.t
https://github.com/bigpresh/Dancer-Plugin-
Database/blob/master/t/lib/TestApp.pm

A test app which exercises the plugin, and a test script that calls the test 
app and checks the results it gets match what's expected.


> 1. Is it considered better to release to Github and then to CPAN per
> Dancer itself?

Generally, yes.  Push to GitHub often, and when you're ready to make a stable 
release, create a tag and release to CPAN (Dist::Zilla can make this very 
easy, although I've not got round to learning to use it yet, I still do it the 
old-school way :) )


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

Well, they should start with "Dancer::Plugin::" really; ideally, try not to be 
too generic if possible to avoid hogging namespaces.  Feel free to describe 
what a plugin does and ask for naming suggestions from the community.

 
> 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.

In general, test for expected behaviour in typical cases, and also test for a 
lack of unexpected behaviour in non-typical cases - e.g. where you don't 
provide an expected parameter, or provide something potentially odd (for 
numeric params, say, a zero value, a negative value, etc).

It's useful to write tests before fixing bugs for regression testing, too - if 
a bug is reported, write a test which tickles the bug and fails, then fix the 
bug - once the test passes, you know you fixed it, and you know if that bug 
comes back in future, that test will catch it.

The Modern Perl book contains a section on testing, although ISTR it's mostly 
high-level guidance on how to write tests, and doesn't really go into a huge 
amount of detail on writing *good* tests.


Cheers

Dave P


-- 
David Precious  ("bigpresh")
http://www.preshweb.co.uk/

   "Programming is like sex. One mistake and you have to support
   it for the rest of your life". (Michael Sinz)