[rspec-users] [Q] how to restructure tests for an abstract class?

Rick DeNatale rick.denatale at gmail.com
Thu Feb 21 11:37:43 EST 2008

On 2/21/08, Chuck Remes <cremes.devlist at mac.com> wrote:
> While practicing BDD on my first-ever BDD project, I have come to a
>  point where it makes sense to change my original class to an abstract
>  class and create one (or more) concrete subclasses that implement a
>  specific method. What is the right way to restructure the tests in
>  this scenario? Do I leave the existing tests in place and just create
>  a new spec file that instantiates and tests the concrete subclass?
>  I think I can continue to instantiate my "abstract" parent as long as
>  I don't go near the behavior that will be defined by the concrete
>  subclasses. Is that the right thing to do?

Let me respond not so much from a BDD/RSpec point of view, but from a
Ruby language perspective.

Abstract classes aren't used much in Ruby, most often the job of
providing "abstract" methods is done by modules rather than classes.

Abstract classes are used in languages which define types via
inheritance like C++ or Java , or provide only single inheritance of
implementation like Smalltalk.

In C++/Java you're pretty much forced to use an abstract class if you
want to provide partial implementation of a type to be filled out by
subclasses.  In Smalltalk they're used to keep things DRY.

In Smalltalk, there are quite a few abstract classes, for example
Collection provides an implementation of methods like select, map,
inject based on subclasses implementing an each method.  In Ruby the
same thing is done by having the Enumerable module which can be mixed
into classes which provide an each method.

So the way I'd approach the kind of refactoring you seem to be
implying would be to move the abstract methods in the existing class
into a module included by that class, and then implement other classes
which also include the module.


Rick DeNatale

My blog on Ruby

More information about the rspec-users mailing list