Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow_value matcher ignores some values #343

Closed
indrekj opened this issue Aug 22, 2013 · 6 comments
Closed

allow_value matcher ignores some values #343

indrekj opened this issue Aug 22, 2013 · 6 comments

Comments

@indrekj
Copy link

indrekj commented Aug 22, 2013

e.g

validating_format(:with => /abc/).
  should_not allow_value('bcd', 'abc').for(:attr)

This assertion should fail because 'abc' is allowed value, but it doesn't.

@mxie
Copy link
Contributor

mxie commented Aug 23, 2013

@indrekj Thanks for putting in this issue! However, this is actually the expected behavior (and in our docs too), i.e. allow_value (when giving multiple values) will fail as soon as it finds a bad one. All others will be ignored/unprocessed.

Closing.

@mxie mxie closed this as completed Aug 23, 2013
@indrekj
Copy link
Author

indrekj commented Aug 23, 2013

Basically, I should never use should_not allow_value(..) with multiple values? I find it a bit odd because should allow_value(...) with multiple values works correctly.

@mxie
Copy link
Contributor

mxie commented Aug 23, 2013

@indrekj Sorry, I'm getting a little confused now. You can definitely use should_not allow_value(..) with multiple values. It's just that if any of those values are not allowed, then its test will fail.

@indrekj
Copy link
Author

indrekj commented Aug 24, 2013

That's the problem. See my initial example. It clearly should fail because of the second value, but it doesn't.

@drapergeek
Copy link
Contributor

@indrekj The problem is that it 'does not' allow the value of 'bcd'. With that single failure, the entire set is rendered as a 'failure' and therefore the test passed. I realize this is a bit confusing but I would recommend splitting your allow values into multiple assertions in this case. The 'should_not' case can get a bit confusing.

@JanDintel
Copy link

@mxie I suggest to reconsider this issue, the current implementation is counter intuitive for the #should_not. See the different issues #175, #197 and my comment on pull request #347

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants