[rspec-users] Propagating settings to subtyped ExampleGroups

Brian Takita brian.takita at gmail.com
Fri Sep 17 14:52:52 EDT 2010


On Wed, Sep 15, 2010 at 9:17 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> 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.
Cool. Btw, nice job on the redesign.
I really like how things are moving toward modules and the metadata.
Things look much more modular and extractable than before.
>
> How does your setup select which of the available ExampleGroup subclasses to instantiate in each case?
The ExampleGroup base classes are registered using
Spec::Example::ExampleGroupFactory.register.
Of course now, it would be done in RSpec.configure. It would be nice
to have the state of the boolean stored in the ExampleGroup class (I'm
assuming the modules get mixed into ExampleGroup).
>
>> 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?
If we can get class method propagation (with state preserved and with
super) working, this should work.

I started experimenting with it, but did not get a working prototype
yet. I'm sortof booked for the next couple of days, but I can play
around with it a bit this weekend.

- Brian
>
>>>>> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list