Support user-supplied metadata for #its

[AlphaHydrae]

I'm working on a test analysis tool which relies heavily on user-supplied metadata such as this:

it "should work", :meta => :data do
  # ...
end

There's currently no way to add metadata to an example defined with its aside from wrapping it in an example group:

subject{ "foo" }
describe "group for metadata", :meta => :data do
  its(:to_s){ should eq("foo") }
end

This is very verbose when you have many its examples. With the changes in this commit, its forwards additional arguments to its internal describe call, allowing this:

subject{ "foo" }
its(:to_s, :meta => :data){ should eq("foo") }

[coveralls]

Coverage increased (+14.52%) when pulling 2a79744 on lotaris:its-metadata into 9362e65 on rspec:master.

[JonRowe]

Thanks for this, just as an FYI if we do merge this it will be extracted to the separate its gem when we get around to that ;)

Also this will need a change log entry...

[JonRowe]

Finicky I know but subject { "foo" } please.

[AlphaHydrae]

You're welcome. I fixed the spacing. Hadn't noticed that convention. I'll add a changelog entry as well.

[coveralls]

Coverage increased (+14.52%) when pulling 78d9bab on lotaris:its-metadata into 9362e65 on rspec:master.

[coveralls]

Coverage increased (+14.52%) when pulling dd817e7 on lotaris:its-metadata into 9362e65 on rspec:master.

[JonRowe]

Change logs entries usually indicate their author ;)

[AlphaHydrae]

Indeed. I am obviously tired today. Sorry about the commit fest.

[JonRowe]

For the record we don't mind squashing and force pushing on PR's but I'm also ok with the 4 commits, I've written worse PR's!

[AlphaHydrae]

Good to know! I'll leave it like this then, so I can put it in my hall of shame. Thanks.

[myronmarston]

@AlphaHydrae - thanks for the well written PR! However, my instinct is to close this w/o merging it for a few reasons:

• As we've previously stated, we're removing its from rspec-core in the next release. I don't want to add to a feature that's going away from this gem before we do another release.
• Users have asked for its to support arguments on multiple occasions (e.g. its(:method_name, :arg_to_method)). While we've resisted adding that to rspec-core's its, once extracted from rspec-core and moved into its own gem, I had always assumed the new maintainers would revisit and potentially add that feature. Unfortunately, it's incompatible with what you've added here: either additional arguments can be forwarded to the method as args or forwarded to describe as args, but not both. So, I'd like to leave it up to the new maintainers of the rspec-its gem to decide which direction they want to go (hopefully getting community feedback) and not eliminate that possibility for them by merging this now.
• IMO, it's non-obvious that the additional args are metadata. I'd be more likely to think they are arguments to the method.
• its isn't meant to be as fully flexible (e.g. with metadata and everything) as normal examples. If you need that flexibility, my recommending is to define an example normally.

Let me know if you have any questions/concerns about this, and thanks again for the good PR. We hope to see more contributions from you in the future.

[AlphaHydrae]

@myronmarston Ok, I see your point. Maybe I'll do another PR in the new gem when the time comes.

I didn't know other users wanted to add arguments. That reminds me of the arguments to it_behaves_like, although it seems less useful for its. But I guess it can make sense. We'll see.

[myronmarston]

I didn't know other users wanted to add arguments.

See #553 and #306.