I'm building a web framework on top of Hunchentoot and I ran into
problems while trying to unit test some of my code. Essentially I need
to unit test behavior that happens accross requests. I want to do it
without starting Hunchentoot by faking the necessary objects (request,
session, etc.)
The documentation says the usual special variables passed to handlers
contain opaque objects. Hunchentoot provides no means of instantiating
them manually (unless I get into internal code, which will tie me to
the implementation). I see two possible solutions:
1. Abstract my code away from Hunchentoot objects. This way I can fake
the necessary environment during unit testing and use Hunchentoot's
environment during the real thing.
2. Create my own objects and make sure all appropriate symbols are
defined for them - essentially faking Huchentoot's API.
It seems like the first option is a better one, but I feel like
Huchentoot should provide some support for this. I'd be happy to hack
it in if I get some direction (as I'm new to Hunchentoot and CL in
general).
--
Regards,
Slava Akhmechet.
On 14 Apr., 05:31, Slava Akhmechet <·········@gmail.com> wrote:
> I'm building a web framework on top of Hunchentoot and I ran into
> problems while trying to unit test some of my code. Essentially I need
> to unit test behavior that happens accross requests. I want to do it
> without starting Hunchentoot by faking the necessary objects (request,
> session, etc.)
Why not just using something like Drakma (lisp-written http-client) to
simulate browser-requests to the server?
This would be alot easier than to rebuild the Hunchentoot API.
ciao,
Jochen
On Apr 14, 9:53 am, ·····@codeartist.org" <····@codeartist.org> wrote:
> Why not just using something like Drakma (lisp-written http-client) to
> simulate browser-requests to the server?
> This would be alot easier than to rebuild the Hunchentoot API.
>
That is a bad way to go about unit testing. Besides being slower in
general (imagine testing db code against a real db instead of a mock
one) you are also performing integration testing and no longer testing
just your code.
On 14 Apr., 18:46, "byronsalty" <··········@gmail.com> wrote:
> On Apr 14, 9:53 am, ·····@codeartist.org" <····@codeartist.org> wrote:
>
> > Why not just using something like Drakma (lisp-written http-client) to
> > simulate browser-requests to the server?
> > This would be alot easier than to rebuild the Hunchentoot API.
>
> That is a bad way to go about unit testing. Besides being slower in
> general (imagine testing db code against a real db instead of a mock
> one) you are also performing integration testing and no longer testing
> just your code.
Well yes ;-) it might be bad - I didn't say that it is the better
solution. I just did mean, that it is the easier one for starters.
If you create a test-suite and mock-code for external dependencies you
will have to debug the mock-code and the test-code too. I therefore
found it a good solution to start with code that calls out to non-mock
modules first and gradually replacing the tests with mock-code
afterwards.
ciao,
Jochen
From: Edi Weitz
Subject: Re: Unit testing Hunchentoot websites
Date:
Message-ID: <u7isf2hfl.fsf@agharta.de>
On Sat, 14 Apr 2007 03:31:42 GMT, Slava Akhmechet <·········@gmail.com> wrote:
> It seems like the first option is a better one, but I feel like
> Huchentoot should provide some support for this.
If you want to discuss what Hunchentoot should provide and what not,
you should better do it on the mailing list.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I saw that you lurk on this group and a lot of others here use
Hunchentoot so I thought it would be a good place to ask a question. I
can crosspost it to Hunchentoot mailing list.
--
Regards,
Slava Akhmechet.