Alex Young
5/17/2007 11:43:00 AM
Brian Candler wrote:
> On Thu, May 17, 2007 at 07:16:53PM +0900, Alex Young wrote:
>> Has anybody looked at cloning XMLRPC::Server instances to run tests
>> suites against? My problem at the moment is that I've got a batch of
>> tests that each need to run against a fresh XMLRPC::Server instance.
>> Starting up one instance takes approximately 1.5 seconds on my computer,
>> which makes running a 100+ test suite rather boring. Cloning the
>> instance before running a test has no measurable impact on the time
>> taken, so I was thinking of making a clone for each test from a single
>> parent instance. However, that doesn't work because each clone after
>> the first is disconnected from the network interface, and I'm not
>> entirely sure how to proceed.
>>
>> Now, what I'm actually trying to test isn't the network stack but rather
>> the XMLRPC interface, so if anybody's got any bright ideas as to how I
>> could do that without involving the server's startup and shutdown
>> sequence, I'm all ears...
>
> Why do you need a fresh XMLRPC server instance each time? Why not create one
> at the start, and run all the tests against it?
So that the tests are as isolated as possible. I'll run into problems
of one test stepping on another one if I do this.
> You can always just reinitialise the object which is being served via
> XMLRPC. At worst, if XMLRPC doesn't let you change what object is being
> served, then you give it a proxy object which delegates to the real handler,
> and then before each test change the proxy object to point to a new handler
> instance.
It's the interface I want to test, not just the object behind it. I'm
already testing the real handler separately. To give a trivial example,
what that doesn't catch is that any method ever returning nil will make
the XMLRPC serialiser barf. I'd much rather have that bubble up as an
exception than explicitly check for it every time.
Just to be clear, I'm using the add_handler(name, &block) form rather
than add_handler(prefix, handler_object) - in this case it lets me wrap
logging and exception trapping code around the main method call, but I
like the fact that I'm not exposing all of Object's methods to the
outside world too.
--
Alex