Evaluating shared example customisation block before shared block

Testing RSpec
41

On Aug 4, 2010, at 3:43 AM, Ashley M. wrote:

I prefer keyword arguments, so I’d like to write:

…

describe “#{collection_name}” do
describe “Helper methods:” do
describe “#new_#{options[:item_name]}, #get_#{options[:item_name]}” do

…

WDYT about RSpec automatically translating keyword options to methods?

What happens if the shared spec author really wants it to just be a
hash? Do you think that’s a valid use case?

42

On 4 Aug 2010, at 1:05 AM, David C. wrote:

One other thought I’ve had is keyword syntax. While currently I’m
writing:

it_satisfies_contract “[Entity] Collection:”, :children, :child,
Child.name

I prefer keyword arguments, so I’d like to write:

it_satisfies_contract “[Entity] Collection:”,
:children,
item_name: “child”,
class_name: Child.name

Currently that would mean rewriting the contract like this:

contract “[Entity] Collection:” do |collection_name, options|

# ...

describe "#{collection_name}" do
  describe "Helper methods:" do
    describe "#new_#{options[:item_name]},

#get_#{options[:item_name]}" do

# ...

WDYT about RSpec automatically translating keyword options to methods?
They’d need to be defined as singleton class methods and instance
methods to have the same availability as block parameters.

Ash

–
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

43

On Aug 4, 2010, at 1:55 AM, Myron M. wrote:

using RSpec 2 after the final release, while still supporting 1.8.6.

Good news: I messed around with module_exec some more, and I think I
have a working implementation for 1.8.6[2]. This was complicated
enough that I wanted to work on it in isolation from RSpec; hence the
separate github project. We’ll probably want to re-organize it a bit
before merging it in, if it’s deemed “good enough” to work for our
needs. It has some specs that pass for module_exec on 1.8.7, and they
pass on 1.8.6 with my implementation, too. There may be cases where
it still doesn’t work quite right, though–feel free to fork, add
specs, etc.

Hey Myron - I think what you have is perfectly fine. The only issue I
ran into was that of defining instance methods, and your solution seems
sound. I wouldn’t even bother to undef those methods. We’re not putting
module_exec in as an API. In fact, in rspec, I think we should change
the names of module_exec and instance_exec to something rspec-specific
so that users don’t rely on our implementation for other purposes.
Something like:

def module_eval_with_args(*args, &block)
if respond_to?(:module_exec)
module_exec(*args, &block)
else
# custom solution
end
end

At that point, as long as all the shared group specs are passing, we’re
good. Make sense?

44

On Aug 4, 2010, at 1:35 PM, Myron M. wrote:

At that point, as long as all the shared group specs are passing, we’re good. Make sense?

Makes total sense. I’ll work on porting this to RSpec, and open an
github issue with a link to the commits when I’m done.

FYI - to those paying attention - I merged Myron’s changes with support
for parameterized shared groups even in 1.8.6.

At this point, the customization block is still being eval’d after the
shared block, and I’m fairly well convinced this is the right thing, in
combination with params to the block.

Next release will FINALLY have parameterized shared groups. Sweet!

Cheers,
David

45

I wouldn’t even bother to undef those methods.

If we don’t undef the methods, then the semantics of the
#module_eval_with_args (or whatever we call it) will be different on
1.8.6 and other versions. On 1.8.6, a method definition in the block
would define both an instance method and a class method. Someone
could write a spec against 1.8.6, and accidentally call the class
method, not realizing they’ve done this, and the spec wouldn’t work on
1.8.7 and above since the class method won’t be there. So I think the
undefs are important, and I don’t think it adds too much complexity.

At that point, as long as all the shared group specs are passing, we’re good. Make sense?
Makes total sense. I’ll work on porting this to RSpec, and open an
github issue with a link to the commits when I’m done.

Thanks!

46

On Aug 04, 2010, at 12:41 pm, David C. wrote:

What happens if the shared spec author really wants it to just be a hash? Do you think that’s a valid use case?

It could get in the way, then, I guess. You’d always have the original
hash parameter if you wanted to use the method, but I guess it could
cause trouble if you did this, or similar:

shared_examples_for “a foo container” do |foo, options = {}|
it “has a #{foo}” do; end
end

describe Bar do
it_should_behave_like “a foo container”, 1, foo: 2
end

I’ll probably play with this idea in my own code. There’s definitely no
need worry about it now, being able to pass arguments to shared example
groups is 90% of the win for me.

Cheers
Ash

–
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

47

On Aug 05, 2010, at 4:28 am, David C. wrote:

At this point, the customization block is still being eval’d after the shared block, and I’m fairly well convinced this is the right thing, in combination with params to the block.

I don’t think it makes any different any more, at least not to me. The
only thing you can’t do is use class methods in shared example
descriptions, but you don’t need to do that any more now anyway.

Next release will FINALLY have parameterized shared groups. Sweet!

Brilliant :slight_smile: What’s the current release plan?

Cheers
Ash

–
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

48

On Aug 6, 2010, at 3:18 AM, Ashley M. wrote:

On Aug 05, 2010, at 4:28 am, David C. wrote:

At this point, the customization block is still being eval’d after the shared block, and I’m fairly well convinced this is the right thing, in combination with params to the block.

I don’t think it makes any different any more, at least not to me. The only thing you can’t do is use class methods in shared example descriptions, but you don’t need to do that any more now anyway.

Next release will FINALLY have parameterized shared groups. Sweet!

Brilliant :slight_smile: What’s the current release plan?

Barring the unforeseen, I’ll knock out beta.20 this weekend.

David

49

On Aug 06, 2010, at 11:58 am, David C. wrote:

Barring the unforeseen, I’ll knock out beta.20 this weekend.

Cool, ta!

Cheers
Ash

–
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran