> Yeah, this is fine for a simple mixin with only one shared behaviour, > but the problem is that a real chunk of mixed-in functionality will > probably need many behaviours that correspond to different initial > states (provided you're behaving yourself and not doing too much state > setup within the individual examples). >
Tom, there is likely a better path then the one I'm going down, and I would love to hear it. I am no RSpec expert. How big are the modules you're including? For the modules I do this with it doesn't seem to get out of hand. The example I gave above was a simplifed version of a module spec, not the whole thing. The real one has many more behaviour blocks, and in the before block a couple hashes for use inside the module spec for creating other scenarios. I'm not doing much setup inside the module spec. If the module has a couple aspects to its behaviour I usually end up with just 2 or 3 describe blocks each with about 20 it blocks, and testing its inclusion into AR classes just needs a before block setting up a half dozen objects. If it's getting too complicated to spec out maybe the module is doing too much and should be split up? Jim _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users