Slava Akhmechet wrote:
Thanks! This is essentially what I wanted to do but you handed it to me on a silver platter :) One question though, why do you create a dummy-request class instead of using hunchentoot's? You could also derive something like unittest-request if you need some special functionality.
If I remember correctly, instantiating hunchentoot::request directly is a bit of a problem as it depends on things like headers-in to be set properly, which needs the server to be started, or at least instantiate a hunchentoot::server object. It didn't seem very efficient as I would be running hundreds of tests, and many of them use request params. So I wanted something very simple to just mock hunchentoot::request's behavior in setting and retrieving params. And I was also too lazy to see if a more generic approach could be taken to this :). So yes, unittest-request looks like a good idea.
Would it make sense to add some functions to Hunchentoot that would provide a public API to do this? This way everyone can unit-test Hunchentoot apps in the same standard way.
Though I can't say I had a detailed look all the unit test frameworks available out there, but I wasn't satisfied with the ones available, so basically I wrote my own on top of Peter Seibel's code in his PCL book. So a unit test framework that is more web-oriented, hunchentoot-compatible seems like a great idea.
Actually there are a couple of times I thought of writing about the same issue to this list, but one thing I was very short on time, and some meddling around seemed to solve my problem. Since you're writing a web framework based on Hunchentoot, seems like we're solving the same problems (I'm adding these bits as I write my webapp) - would love to collaborate where I can.
Regards, Vamsee.