Re: Dancer bugs? send_file(), content type, and response_content_is()

[pokki]

Regarding "the best way" of serving Javascript files, you should just put them in the /public directory and remove your /javascripts route. Any request that does not match a route, e.g. GET /foo/bar.js will look into /public for a file called /public/foo/bar.js and serve that directly; if it doesn't exist you get a 404 as expected. In your case you're not using system_path in your call to send_file, so the file will only be served from the public directory anyway...

I've looked at the source for send_file and it does seem to propagate the MIME type from the function call to the rendering of the response. However, I've been bitten by Dancer::Test before. Since it's returning a filehandle instead of a rendered response I'd say it's not calling get_file_response_for_path from Dancer::Renderer, which is responsible for adding the Content-Type header. In short, don't expect Dancer::Test to mimic a real web app from end to end. It's there to allow you to test plugins and such. Regarding response_exists, that does seem like a documentation bug.

Finally, rest assured that Dancer *is* a mature framework. We use it at $work for many internal applications and we have never had serious problems.

The Dancer folk at #dancer on irc.perl.org are very responsive and friendly, be sure to check there if you have other questions.

[hardburn]

The files I had were under /public/javascripts. They just don't show up that way in the routes. As far as getting things over a browser was concerned, the file was transferred as expected. Dancer's test framework was the problem.

I'm doing this as part of a comparison with Mojolicious for a possible future app at $work. Given that we will want tight unit testing, and that Mojo's test framework seems much more sophisticated, I'm leaning that way.

[pokki]

The files I had were under /public/javascripts. They just don't show up that way in the routes. As far as getting things over a browser was concerned, the file was transferred as expected. Dancer's test framework was the problem.

There is no explicit route associated with stuff in /public. Rather, when Dancer finds no route matching a given request, it tries to find a file in /public. If there is still no match there, then 404. This still serves files in /public via send_file though, unlike regular template rendering, so you'd still get a filehandle and Dancer::Test would still be useless. (Fortunately there is little reason to test that Dancer's static file management works. That's already been tested, in Dancer's own test suite.)

I'm doing this as part of a comparison with Mojolicious for a possible future app at $work. Given that we will want tight unit testing, and that Mojo's test framework seems much more sophisticated, I'm leaning that way.

I can't offer any honest opinion on Dancer vs. Mojo, because I haven't tried Mojo at all. (I dislike their philosophy of never reusing the CPAN, reinventing everything by themselves, and keeping it all inside a monolithic distribution so that no one can reuse it either. I have no opinion on the technical merits of Mojo.)

Regarding unit testing of web apps, I'm not a fan of unit-testing them from request to rendered response because any change in the template for instance is likely to break your tests, and large pages with a lot of information are a pain to test against. I'd rather test separately that the values I'm passing to the template are what I expect, and then that the template renders correctly when passed certain values. This can be done with regular unit testing, like any module. Automated end-to-end testing of web apps, outside of Selenium and similar technologies, doesn't really work in my relatively limited experience.