On Mon, Feb 25, 2008 at 6:23 AM, Chuck Remes <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > On Thu, Feb 21, 2008 at 8:09 AM, Chuck Remes <[EMAIL PROTECTED]> > 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@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@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
