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)