[rspec-users] Propagating settings to subtyped ExampleGroups

David Chelimsky dchelimsky at gmail.com
Thu Sep 16 00:17:00 EDT 2010


On Sep 14, 2010, at 11:04 AM, Brian Takita wrote:

> On Tue, Sep 14, 2010 at 6:27 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> Hey Brian - long time. Hope all is well. More below ...
> Hey David, I've been pretty busy, and things are going well. It seems
> like things are going well with you :-)
>> 
>> On Sep 14, 2010, at 12:04 AM, Justin Ko wrote:
>> 
>>> On Sep 14, 12:31 am, Brian Takita <brian.tak... at gmail.com> wrote:
>>>> Hey, rspec 2 upgrade question.
>>>> 
>>>> Rspec 1.x had a class hierarchy. In a Rails project, the ExampleGroup
>>>> inherited from Test::Unit::TestCase.
>>>> That allowed me to set use_transactional_fixtures in my own
>>>> ExampleGroups and rely on inheritance for the settings to propagate.
>> 
>> How are you telling rspec to load which example groups? Maybe we can accomplish the same with mixins.
> I converted the ExampleGroups into mixins, but there are some issues.
> Basically, I made ExampleGroup classes (with class methods). The class
> methods also relied on inheritance (to use super).
> There are complications with the new architecture. I'm trying to
> figure out if my architecture is "compatible" with RSpec 2.0.
>> 
>>>> Now it seems like RSpec::Core::ExampleGroup no longer inherits from
>>>> Test::Unit::TestCase and there is RSpec.configure instead.
>> 
>> Not instead - there was always Spec.configure - but yes, I worked with the Rails core team to make it so RSpec didn't need to depend on the Test::Unit or Minitest runners but could still get all the services in rails tests.
> True. I always preferred setting use_transactional_fixtures directly
> in the ExampleGroup because it is more straightforward (less software
> needed and less things breaking until now) and worked really well with
> the inheritance hierarchy.
> I could override use_transactional_fixtures in subclasses.
>> 
>> Now we use metadata set on groups to determine when to mix in what behaviour:
>> 
>> module MyExtension
>>  ...
>> end
>> 
>> RSpec.configure do |c|
>>  c.include(MyExtension, :foo => :bar)
>> end
>> 
>> describe "something", :foo => :bar do
>>  ...
>> end
>> 
>> In rspec-rails, that's done implicitly by matching the :type key in the metadata, which gets set before RSpec.configure is processed.  You could do something similar if you wanted to make these inclusions work implicitly based on some other criteria like directory path, etc.
>> 
>> That all make sense? If not, can you give me a clearer picture of  your use case?
> I have different subclasses of ExampleGroup. I use instance and class
> method overriding. I also call class methods (defined in the parent or
> current class) in the ExampleGroup definitions.

How does your setup select which of the available ExampleGroup subclasses to instantiate in each case?

> The metadata is interesting. I'm trying to figure out how module
> inheritance & metadata can be used as a substitute.
> 
> Correct me if I'm wrong about my following points:
> If I were to use the metadata, I have to sort of reimplement the class
> method inheritance (for class methods from Test::Unit such as
> use_transactional_fixtures) using the metadata.
> 
> If the class method is originally defined in rspec, I can somehow
> wrangle module inheritance to properly handle class methods. However,
> in this case, it's simpler with class inheritance.

How would you see this working, given the existing architectural changes?

>>>> How do I have the settings in the configuration propagate to subtypes
>>>> of the ExampleGroup?
>>> describe 'I want this to be inherited' do
>>>  before do
>>>    RSpec.configure {|c| c.use_transactional_fixtures = false }
>>>  end
> I'm surprised that would that work. I would think that Fixture loading
> would be one of the first before blocks and would occur before the
> configure statement.
> I suppose if you could somehow prepend the before block to the front
> of everything, it would work.
>>> 
>>>  context 'blah' do
>>> 
>>> I would wrap it in a method if you're doing it often.
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
> Thank you,
> Brian
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list