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.