[rspec-users] What's the best way to test inherited behavior?

Dan North tastapod at gmail.com
Fri Oct 10 04:48:27 EDT 2008


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 <matt at mattwynne.net>

> 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
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081010/94ed57cd/attachment.html>


More information about the rspec-users mailing list