This repository has been archived by the owner. It is now read-only.

Recommend wrapping or aliasing matchers #1

Closed
dchelimsky opened this Issue Nov 26, 2011 · 7 comments

Comments

Projects
None yet
2 participants
@dchelimsky

This is from the README:

it { should assign :blah => be_a(String) }

Using the infinitive form of the verb reads funny in this context, so I'd recommend aliasing that with a present tense form or an adjective:

it { should assign :blah => is_a(String) }
it { should assign :blah => instance_of(String) }
@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Nov 26, 2011

Similarly, the description should be "should assign a String to @BLAH" rather than "should assign @BLAH to be a kind of String". Might want to consider a set of custom matchers for this.

Similarly, the description should be "should assign a String to @BLAH" rather than "should assign @BLAH to be a kind of String". Might want to consider a set of custom matchers for this.

@sj26

This comment has been minimized.

Show comment
Hide comment
@sj26

sj26 Nov 26, 2011

Owner

Agreed, I was not aware of alternate forms of these matchers, or are you suggesting adding aliases? This was the primary reason I was using assign(:blah).to be_a String.

I'd be hesitant to alias every core rspec matcher to cater for this particular matcher.

Owner

sj26 commented Nov 26, 2011

Agreed, I was not aware of alternate forms of these matchers, or are you suggesting adding aliases? This was the primary reason I was using assign(:blah).to be_a String.

I'd be hesitant to alias every core rspec matcher to cater for this particular matcher.

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Nov 26, 2011

I appreciate the hesitation, but I wonder how far this really needs to go. Besides literal values and is_a, what other matchers do you see being used?

I appreciate the hesitation, but I wonder how far this really needs to go. Besides literal values and is_a, what other matchers do you see being used?

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Nov 26, 2011

BTW - rspec-mocks has a bunch of these (see ArgumentMatchers on http://rubydoc.info/github/rspec/rspec-mocks/master/file/README.md). Maybe in rspec-3 we should normalize the matchers and pull them out to a separate library like Hamcrest.

BTW - rspec-mocks has a bunch of these (see ArgumentMatchers on http://rubydoc.info/github/rspec/rspec-mocks/master/file/README.md). Maybe in rspec-3 we should normalize the matchers and pull them out to a separate library like Hamcrest.

@sj26

This comment has been minimized.

Show comment
Hide comment
@sj26

sj26 Nov 26, 2011

Owner

True, I was mainly thinking of be_<predicate> matchers, like be_empty, be_admin, etc., which can be useful when testing properties of an exposed ActiveRecord object for instance. This could be achieved easily by adding a method_missing catch for is_<predicate> aliased to BePredicate.

Unfortunately most of my company's projects use RR. :-( I've found it quite restrictive lately, mainly in testing blocks, and am trying to spearhead a change to rspec mocks.

It would be nice to have a ubiquitous set of matchers. A lot of matcher functionality was reimplemented inside AssignMatcher because I couldn't find a nice way to reuse it. Hamcrest looks neat!

I think an ideal implementation of this matcher would actually be a subject modifier, not a matcher at all. Something in the vein of it_assigns(:blah) { should be_present }.

Owner

sj26 commented Nov 26, 2011

True, I was mainly thinking of be_<predicate> matchers, like be_empty, be_admin, etc., which can be useful when testing properties of an exposed ActiveRecord object for instance. This could be achieved easily by adding a method_missing catch for is_<predicate> aliased to BePredicate.

Unfortunately most of my company's projects use RR. :-( I've found it quite restrictive lately, mainly in testing blocks, and am trying to spearhead a change to rspec mocks.

It would be nice to have a ubiquitous set of matchers. A lot of matcher functionality was reimplemented inside AssignMatcher because I couldn't find a nice way to reuse it. Hamcrest looks neat!

I think an ideal implementation of this matcher would actually be a subject modifier, not a matcher at all. Something in the vein of it_assigns(:blah) { should be_present }.

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Nov 26, 2011

I'd avoid adding new syntax. The current form is consistent with the it { should matcher } form. I also think it reads better as/is. The spec is that the controller assigns something. That the something should have some quality is a secondary aspect. Saying it_assigns(:var) { should match(value) } reverses those roles and doesn't read as well IMO.

I'd avoid adding new syntax. The current form is consistent with the it { should matcher } form. I also think it reads better as/is. The spec is that the controller assigns something. That the something should have some quality is a secondary aspect. Saying it_assigns(:var) { should match(value) } reverses those roles and doesn't read as well IMO.

@sj26

This comment has been minimized.

Show comment
Hide comment
@sj26

sj26 Nov 26, 2011

Owner

Again agreed, which is why I chose the matcher route. I think form-changing matcher aliases sate my desire for readability. :-)

Owner

sj26 commented Nov 26, 2011

Again agreed, which is why I chose the matcher route. I think form-changing matcher aliases sate my desire for readability. :-)

@sj26 sj26 closed this Jun 11, 2018

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