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?
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?
Rspec 1.x had a class hierarchy. In a Rails project, the ExampleGroup
Now we use metadata set on groups to determine when to mix in what behaviour:
…
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?
in this case, it’s simpler with class inheritance.
How would you see this working, given the existing architectural
changes?
On Sep 14, 12:31 am, Brian T. [email protected] wrote:
methods also relied on inheritance (to use super).
the inheritance hierarchy.
end
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).
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.
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
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.
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.
