rspec users - Sep 2010 - Propagating settings to subtyped ExampleGroups

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.

Now it seems like RSpec::Core::ExampleGroup no longer inherits from
Test::Unit::TestCase and there is RSpec.configure instead.
How do I have the settings in the configuration propagate to subtypes
of the ExampleGroup?

Thanks,
Brian

describe ''I want this to be inherited'' do
  before do
    RSpec.configure {|c| c.use_transactional_fixtures = false }
  end

  context ''blah'' do

I would wrap it in a method if you''re doing it often.

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.
>
> Now it seems like RSpec::Core::ExampleGroup no longer inherits from
> Test::Unit::TestCase and there is RSpec.configure instead.
> How do I have the settings in the configuration propagate to subtypes
> of the ExampleGroup?
>
> Thanks,
> Brian
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

Hey Brian - long time. Hope all is well. More below ...

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.
>> 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.

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?
>> 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
> 
>  context ''blah'' do
> 
> I would wrap it in a method if you''re doing it often.

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.
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 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

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

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
>