Another approach would be to prefer composition over inheritance<http://www.google.com/search?q=prefer%20composition%20over%20inheritance>, and either inject the server in a constructor (with a suitable name for the class) or mix it in as a module.
Then you could describe the common server behaviour in one set of examples, and just have a couple of mock-based examples to verify that the "subclasses" interact correctly with the Server. Cheers, Dan 2008/10/10 Matt Wynne <[EMAIL PROTECTED]> > On 9 Oct 2008, at 20:35, Hongli Lai wrote: > > Pat Maddox wrote: >> >>> I've written [1] about using shared example groups to do this sort of >>> things. You're already using them :) but maybe you can still get >>> something out of that post. >>> What specifically don't you like about this solution? >>> >> >> What Matt proposed is very nice. :) I was struggling with finding a good >> way to name my specs. >> > > ta! :) > > However, by calling the shared example "a server" I can still end up with >> weird names: >> >> describe FrameworkSpawner >> describe "when in conservative spawning mode" >> before :each do >> .. >> end >> >> it_should_behave_like "an AbstractServer" >> end >> >> describe "when in smart spawning mode" >> before :each do >> end >> >> it_should_behave_like "an AbstractServer" >> end >> end >> >> So I can end up with a weird sentence like: >> "FrameworkSpawner when in smart spawning mode an AbstractServer raises >> AlreadyStarted if the child process is still running" >> > > You're right, these do read funny don't they? > > I still don't think you've got far enough along the > implementation->behavioiur spectrum in your example names and that's partly > why it still feels weird. I'd rid of that reference to the AbstractServer > altogether, for starters. > > Don't forget that the name of the shared example group does not go into the > specdoc - it's just a label you use when pulling it in with > it_should_behave_like. > > Maybe you could put another ExampleGroup block inside your shared group to > describe the context? > > e.g.: "FrameworkSpawner when in smart spawning mode when the child process > is still running should raise an AlreadyStarted error" > > Also bear in mind that you can split your shared behaviour and have more > than one shared example group, and 'mix them in' to define the appropriate > behaviour in different contexts. > > > > Shared example groups *are* a blessing. Just the constructed sentences >> bother me sometimes. :) I'm also wondering whether it's a good idea to test >> my child classes like this, or whether I should test the parent class >> separately, and not test the child classes for the parent class's behaviors. >> _______________________________________________ >> rspec-users mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
