Add support for subject(:name) { ... } #619

Closed
dchelimsky opened this Issue May 15, 2012 · 13 comments

Comments

Projects
None yet
5 participants
@dchelimsky
Member

dchelimsky commented May 15, 2012

describe Article do
  subject(:article) { Article.new }
  it { should support_one_liners }
  it "should be exposed with the name :article" do
    article.should support_intention_revealing_name
  end
end

See the following for background:

http://blog.davidchelimsky.net/2012/05/13/spec-smell-explicit-use-of-subject/
https://gist.github.com/2705101
https://gist.github.com/2705200

@avdi

This comment has been minimized.

Show comment
Hide comment
@avdi

avdi May 15, 2012

Heh, I was just about to suggest exactly that :-)

avdi commented May 15, 2012

Heh, I was just about to suggest exactly that :-)

@soulcutter

This comment has been minimized.

Show comment
Hide comment
@soulcutter

soulcutter May 15, 2012

Member

Good deal.

Member

soulcutter commented May 15, 2012

Good deal.

dchelimsky added a commit that referenced this issue May 16, 2012

@nicksieger

This comment has been minimized.

Show comment
Hide comment
@nicksieger

nicksieger May 16, 2012

Next step would be to deprecate Example#subject :)

Next step would be to deprecate Example#subject :)

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky May 16, 2012

Member

@nicksieger I could deprecate it in the docs, but not programatically, because it's needed for one-liners.

Member

dchelimsky commented May 16, 2012

@nicksieger I could deprecate it in the docs, but not programatically, because it's needed for one-liners.

@avdi

This comment has been minimized.

Show comment
Hide comment
@avdi

avdi May 16, 2012

And for shared specs.

avdi commented May 16, 2012

And for shared specs.

@nicksieger

This comment has been minimized.

Show comment
Hide comment
@nicksieger

nicksieger May 16, 2012

Oh, of course. #subject is used internally in the framework.

Oh, of course. #subject is used internally in the framework.

dchelimsky added a commit that referenced this issue May 16, 2012

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky May 16, 2012

Member

@avdi I'd argue that in most cases you can do better than "subject", even in shared specs.

Member

dchelimsky commented May 16, 2012

@avdi I'd argue that in most cases you can do better than "subject", even in shared specs.

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky May 16, 2012

Member

@avdi ... unless you're using the implicit subject built from the described_class, but then you could just reference described_class, which I think is a more descriptive name than subject. YMMV :)

Member

dchelimsky commented May 16, 2012

@avdi ... unless you're using the implicit subject built from the described_class, but then you could just reference described_class, which I think is a more descriptive name than subject. YMMV :)

@justinko

This comment has been minimized.

Show comment
Hide comment
@justinko

justinko May 16, 2012

Contributor

I'd argue that in most cases you can do better than "subject", even in shared specs.

All methods of sharing accept arguments (and soon to be blocks). 🤘

Contributor

justinko commented May 16, 2012

I'd argue that in most cases you can do better than "subject", even in shared specs.

All methods of sharing accept arguments (and soon to be blocks). 🤘

@avdi

This comment has been minimized.

Show comment
Hide comment
@avdi

avdi May 16, 2012

For shared specs that ensure compliance with a protocol I think it's
important to have a broad convention for "object under test", so that
writers of client specs can do the least surprising thing (implement
subject and include the shared spec) and have it work (or fail, showing
them what part of the protocol to implement next).

avdi commented May 16, 2012

For shared specs that ensure compliance with a protocol I think it's
important to have a broad convention for "object under test", so that
writers of client specs can do the least surprising thing (implement
subject and include the shared spec) and have it work (or fail, showing
them what part of the protocol to implement next).

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky May 16, 2012

Member

@avdi - but that protocol has a name. If the specs are for things that implement that protocol, then you can use that name or something similar. If you're spec'ing a consumer of the protocol, then "consumer" might be a good name. "subject" doesn't tell you anything about either, unless it's one of the subjects who bow to you in your kingdom.

Member

dchelimsky commented May 16, 2012

@avdi - but that protocol has a name. If the specs are for things that implement that protocol, then you can use that name or something similar. If you're spec'ing a consumer of the protocol, then "consumer" might be a good name. "subject" doesn't tell you anything about either, unless it's one of the subjects who bow to you in your kingdom.

@avdi

This comment has been minimized.

Show comment
Hide comment
@avdi

avdi May 16, 2012

So when I write a whole spec for my Wodget, then decide I want it to
implement your fribble protocol as well, do I have to dig through code
and/or locate the docs to figure out what your shared specs are expecting
to find?

avdi commented May 16, 2012

So when I write a whole spec for my Wodget, then decide I want it to
implement your fribble protocol as well, do I have to dig through code
and/or locate the docs to figure out what your shared specs are expecting
to find?

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky May 16, 2012

Member

@avdi if you were going to add shared specs from my fribble-protocol lib, you'd probably start with docs because you'd need to know the name to pass to it_behaves_like, and those same docs would tell you what to put in the block. But even if you failed to read that part, you'd get a NameError when the shared spec references fribble_drinker, or the shared spec could detect the presence of the method first and then, with a friendly tone, guide you to "awful awful" happiness.

Member

dchelimsky commented May 16, 2012

@avdi if you were going to add shared specs from my fribble-protocol lib, you'd probably start with docs because you'd need to know the name to pass to it_behaves_like, and those same docs would tell you what to put in the block. But even if you failed to read that part, you'd get a NameError when the shared spec references fribble_drinker, or the shared spec could detect the presence of the method first and then, with a friendly tone, guide you to "awful awful" happiness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment