[rspec-users] help with test design

Chuck Remes cremes.devlist at mac.com
Wed Jun 11 13:06:19 EDT 2008

I'm having trouble figuring out how to drive the design of a class.  
I'm hoping I can get a hint or two from the more experienced BDDers on  
this list.

I'm writing an adapter class that sits between a 3rd party library and  
my business logic. I would like to extract some information from  
objects available from the 3rd party lib and covert them into ruby  
objects. My desire is to insulate my ruby business logic from changes  
in the 3rd party library by putting all of this conversion code into a  
single adapter class (and some related "event" classes).

Using BDD techniques I have created a pretty simple interface  to the  
adapter class. So far the adapter class has two main public methods  
(plus a bunch of accessors to allow the dependency injection).

- this method calls into the 3rd party library and pulls out the  
3rdPartyInstrument object and stores it off for further manipulation

- this method permanently saves the 3rdPartyInstrument if it is a  
FUTURE, or if it is a COMBINATION it iterates through each  
sub-3rdPartyInstrument and saves it off

Using mocks and ruby's brain-dead simple support for dependency  
injection I have been able to mock out and verify this behavior.

Now I need to add another public method which I will call  
#generate_internal_instruments. What I would like this method to do is  
iterate through my #components and create two related objects. Object  
one will be my RubyInstrument class (called something else, but this  
will suffice) and a second is a RubyInstrumentCreationEvent. The  
intention is to pass the 3rdParty component to  
RubyInstrumentCreationEvent.new(component) where it will extract all  
salient details from the 3rdParty component (again, this is for  
insulating the business logic from knowing this 3rd Party lib). Then I  
will pass this RubyInstrumentCreationEvent to RubyInstrument.new (or  
RubyInstrument.build) where it will finish the construction of itself.

Ideally, all of these steps would be private to the Adapter class and  
would expose a single public interface called #build. All of these  
public methods exist solely so I can test these specific behaviors.

Any suggestions on how to accomplish my goals? Is my difficulty  
pointing at a code smell that I am not detecting?


More information about the rspec-users mailing list