On 2/21/08, 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?
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. HTH -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
