# Testing XMLRPC::Servers **URL:** \ **Category:** Ruby\ **Created:** [May 17, 2007, 12:18pm UTC](https://www.ruby-forum.com/t/testing-xmlrpc-servers/104381 "2007-05-17T12:18:24Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\ **Post date:** [May 17, 2007, 12:18pm UTC](https://www.ruby-forum.com/t/testing-xmlrpc-servers/104381/1 "2007-05-17T12:18:24Z")
Hi all, 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… ---
**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\ **Post date:** [May 17, 2007, 1:28pm UTC](https://www.ruby-forum.com/t/testing-xmlrpc-servers/104381/2 "2007-05-17T13:28:06Z")
On Thu, May 17, 2007 at 07:16:53PM +0900, Alex Y. wrote: > 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? 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. Regards, Brian. ---
**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\ **Post date:** [May 17, 2007, 1:43pm UTC](https://www.ruby-forum.com/t/testing-xmlrpc-servers/104381/3 "2007-05-17T13:43:07Z")
Brian C. wrote: > > 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.