Help with test design

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).

#discover_instruments

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

#save_components

  • 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?

cr

On Wed, Jun 11, 2008 at 10:06 AM, Chuck R. [email protected]
wrote:

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?

I feel a bit brain-dead today, so take this with a grain of salt…but
after reading through your email several times, I’m not sure what your
goals are, what you’ve currently tried, and what particular problems
you’re experiencing.

Pat

On Jun 11, 2008, at 12:06 PM, Chuck R. wrote:

FUTURE, or if it is a COMBINATION it iterates through each
RubyInstrumentCreationEvent. The intention is to pass the 3rdParty
behaviors.

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

Hey Chuck - sounds like you’re trying to plan the whole process out up
front. TDD is about discovery. Here’s what I’d recommend:

Start w/ a simple example of what you want the adapter to do - the
simplest think you can think of - when you send it the
#generate_internal_instruments message. Get that to pass. Now the next
simplest thing. Get that to pass. Refactor. Rinse. Repeat.

As you do this, the method might start to do too much and you’ll see
opportunities to break it up into smaller private methods or perhaps
even methods on a brand new object you don’t know about yet. That’s
all good. Let the design emerge.

If/when you do choose to move things out to other classes, you may
want to introduce new mocks in the examples and move some of the
examples to the group describing the new object. That’s all fine.

Don’t anticipate code smells, but keep sniffing. When you do smell
them, deal with them immediately. Don’t wait.

HTH,
David

Forwarded message from Chuck R.:

Begin forwarded message: