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

David Chelimsky dchelimsky at gmail.com
Mon Feb 25 09:30:47 EST 2008


On Mon, Feb 25, 2008 at 6:23 AM, Chuck Remes <cremes.devlist at mac.com> wrote:
> Thanks for asking this question. This is exactly what I was going to write,
> but you beat me to it!
>
> (Sorry for the top-post; just following the last responder.)
>
> cr
>
>
>
> On Feb 25, 2008, at 3:30 AM, Matthijs Langenberg wrote:
> Question is, would you duplicate the specs for all the classes that include
> a certain module (through shared behaviour for example), or would you use
> one set of specs for just the module, and specify that a class should
> include that module?

Matthijs - I'd throw the same question back to you. Have you tried
both approaches? How have they worked out for you?

I won't wait for your answer :). But I am curious about other people's
experiences with this.

I can tell you this from my own experience - I tend to use shared
groups for this for a couple of reasons. One, I like to see the specs
for each object. Seeing this ....

Thing
- should include the Foo module

in the spec output doesn't really help me understand what Thing does.

Keep in mind that including a module does not guarantee that the
methods in that module are used. They can be redefined. They can also
behave differently depending on the state of the including object. For
these reasons, I generally don't really like to specify module
inclusion.

I try to approach this from the perspective of "how do I want
instances of this type to behave?" When I find duplication in
behaviour across types, I may extract a shared example group.

The discipline challenge really comes in when I already have a shared
group and I'm adding a new type and my inner designer is quite certain
that it should include the same module. I can tell you that I've gone
at this from two directions - either spec'ing the new type cold or
just including the shared group in the spec for the type and including
the module. Neither route has been perfect every time :)

Hope that helps ... a little.

Cheers,
David


>
> On Sun, Feb 24, 2008 at 12:19 AM, Pat Maddox <pergesu at gmail.com> wrote:
> >
> >
> >
> > On Thu, Feb 21, 2008 at 8:09 AM, 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?
> > >
> > >  Thanks for any hints.
> > >
> > >  cr
> > >  _______________________________________________
> > >  rspec-users mailing list
> > >  rspec-users at rubyforge.org
> > >  http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> >
> > I think that shared example groups might be useful.
> >
> > Pat
> >
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>  _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
>  rspec-users mailing list
>  rspec-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list