On Wed, Aug 3, 2011 at 6:00 AM, <dancer-users-request@perldancer.org> wrote:
From: sawyer x <xsawyerx@gmail.com> Subject: Re: [Dancer-users] Writing tests for Dancer::Plugins
Hi, Thanks for the welcome and the information. Sorry for the delayed response. I'm trying to get a project pushed out at work. Also sorry if this reply is out of context, I was subscribed to the list digest when I first posted. I was also wondering if there is a list of any Dancer apps floating around. I saw the links on perldancer.org, but from looking through them it seems that Dancer is being used just for parsing the URLs. That isn't a criticism of course, I'm just super curious and I would like to find some examples of applications built around Dancer so that I can try and learn the style that is used. For example what is the most common method for session storage, data storage, etc. Obviously I'm reading the documentation, but I would love to look through some real-life code too. We currently produce Apache/CGI applications so I think Dancer would be a huge difference since it would likely let us run things much faster and we would be able to slot in new actions so much more easily to make development easier. Of course there's still the convincing the boss part of it that needs to be done :-) but that might be easier with some smaller projects in Dancer.
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.
Thank you for the info. I hadn't seen Test::TinyMocker before so I'll look at that. When I write tests (I know, it sounds horrible) I do use Test::More. I mostly wanted to see what suggestions anyone had since the code is available through the application as well as directly in the library.
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"
Thanks. That is a surprisingly helpful guide to keep in mind.
Hope this helps, Sawyer.
It does. Thank you. Colin.