[Dancer-users] Dancer-users Digest, Vol 18, Issue 4

[Colin Keith]

On Thu, Aug 4, 2011 at 6:00 AM,  <dancer-users-request at perldancer.org> wrote:
> From: David Precious <davidp at preshweb.co.uk>
> Subject: Re: [Dancer-users] Writing tests for Dancer::Plugins
> To: dancer-users at perldancer.org
> Message-ID: <201108031317.59264.davidp at preshweb.co.uk>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Wednesday 03 August 2011 06:06:07 Colin Keith wrote:
> 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.


Ahh, thank you. I knew I had seen that approach used in a module's
test code, but I couldn't remember which it was.


> 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 :) )

Okay, thank you for the advice.

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

I wrote a plugin to Locale::TextDomain as I find it the easiest
interface to libgettext (after I bashed my head against the desk with
all of them).

I use it in my TT templates in our software to allow owners of the
software to customize the test, particularly the language of the text
that is output so I called my lib

Dancer::Plugin::I18N::TextDomain

I assume that there would be alternative plugins for other i18n
interfaces so I didn't want to hog the I18N name space.


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

Thank you. I usually just get on and fix them, but that is a very
helpful suggestion.

Colin.