# Test::Unit and drb

**URL:** <https://www.ruby-forum.com/t/test-unit-and-drb/77784>\
**Category:** Ruby\
**Created:** [November 30, 2006, 3:07pm UTC](https://www.ruby-forum.com/t/test-unit-and-drb/77784 "2006-11-30T15:07:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 30, 2006, 3:07pm UTC](https://www.ruby-forum.com/t/test-unit-and-drb/77784/1 "2006-11-30T15:07:59Z")

</div>

Anybody have any tips to share about unit testing code that uses drb?

My problem is, I can test all the the logic in smaller chunks, but as  
soon as I integrate everyhting and have code in place that verifies and  
recovers from connection errors I need to at least establish that drb  
connection.

How would I go about doing this in a unit test environment?  
Getting a mock drb server in a thread and launching it in setup seems  
too clunky.  
Any brilliant ideas?  
Cheers,  
V.-

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 30, 2006, 3:14pm UTC](https://www.ruby-forum.com/t/test-unit-and-drb/77784/2 "2006-11-30T15:14:00Z")

</div>

On 30/11/06, Damphyr [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> ## Any brilliant ideas? Cheers, V.-
> 
> [http://www.braveworld.net/riva](http://www.braveworld.net/riva)

This is how I’ve done it though if anyone has better solutions I’d be  
glad to hear them:

require ‘drb’  
require ‘test/unit’

class Counter  
def initialize;@counter = 0;end  
def count;@counter+=1;end

def self.start  
DRb.start\_service(“druby://localhost:9000”,self.new)  
end

def stop  
DRb.stop\_service  
end  
end

class TC\_Counter \< Test::Unit::TestCase  
def setup  
@t = Thread.new do  
Counter.start  
end  
@counter = DRbObject.new\_with\_uri(“druby://localhost:9000”)  
end

def teardown  
@counter.stop  
@t.exit  
end

def test\_count  
assert\_equal(1,@counter.count)  
assert\_equal(2,@counter.count)  
assert\_equal(3,@counter.count)  
end  
end

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 1, 2006, 2:58am UTC](https://www.ruby-forum.com/t/test-unit-and-drb/77784/3 "2006-12-01T02:58:25Z")

</div>

On Nov 30, 2006, at 0605 , Damphyr wrote:

> Anybody have any tips to share about unit testing code that uses drb?
> 
> My problem is, I can test all the the logic in smaller chunks, but  
> as soon as I integrate everyhting and have code in place that  
> verifies and recovers from connection errors I need to at least  
> establish that drb connection.

How is multiprocess operation (DRb dispatched) different from  
multithreaded operation (method calls) for your program?

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)

I LIT YOUR GEM ON FIRE!

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 1, 2006, 10:55am UTC](https://www.ruby-forum.com/t/test-unit-and-drb/77784/4 "2006-12-01T10:55:16Z")

</div>

Eric H. wrote:

> multithreaded operation (method calls) for your program?  
> It’s not, apart from the fact that the drb server might just not be  
> there, so I need to recover from network errors in some way.  
> I am testing everything before putting it together and I am testing  
> without a drb connection.  
> Thing is in one case I make two or three calls over drb and at the  
> moment I can only test what happens when the first call fails, but not  
> what happens when the connection goes away in between calls.  
> The whole scenario is more of an integration test and fitting it into  
> Test::Unit is a bit of a push.  
> Cheers,  
> V.-