On Sep 14, 2010, at 11:04 AM, Brian Takita wrote:
> On Tue, Sep 14, 2010 at 6:27 AM, David Chelimsky <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> Thank you,
> Brian
> _______________________________________________
> 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
