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
