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

Adding loose comparison -- code, and pull request if interested. #50

Open
jejacks0n opened this issue Aug 30, 2013 · 5 comments
Open

Adding loose comparison -- code, and pull request if interested. #50

jejacks0n opened this issue Aug 30, 2013 · 5 comments

Comments

@jejacks0n
Copy link

I wanted a loose comparison type of thing so I threw one together. I'm wondering if this is a feature worth implementing, and if so, I'll submit a pull request with proper specs and an adjusted matcher name -- if not someone else might find this useful.

gist: https://gist.github.com/jejacks0n/6384919

This allows specifying attributes that you want to ensure are there, but that you don't really care about the value of by using a wildcard (*).

eg.

expect(response_body).to look_like <<-JSON
  {
    "access_token": "*",
    "token_type": "bearer",
  }
JSON

Thoughts / feelings? If it's something worth adding, what would you like me to change?

@laserlemon
Copy link
Contributor

I'm leery of the syntax because the "*" syntax is perfectly valid JSON. Plus this is possible using a different combination of matcher, although it might not be as short. I'd like to hear others' thoughts.

@jejacks0n
Copy link
Author

Yeah, that's why I'm posting it as a question instead of spending time on the pull request first.. I find it useful -- I'm using RSpec API Documentation (which is great), and wanted the specs to be a little more readable.. it's usefulness is limited for sure, but I think there's value in having the spec read nicely as well as the documentation.

I've used something like this on a different project in cucumber and actually found it to be much more useful there.. My RSpec example is how I'm using it, but I think there's an argument for it. For instance, I don't like the idea of excluding created_at and updated_at, etc.. at a global level.. I want to document as well as ensure that they're in the response, I just don't care what their value is. The current library only supports excluding them entirely and this allows for them to be asserted as being there.

@jejacks0n
Copy link
Author

If there's a different way to accomplish this I would like to know -- I dug around but didn't see anything obvious.

Thanks for the good library btw. =)

@laserlemon
Copy link
Contributor

If you don't care about the values, you could achieve the same result using the have_json_path matcher. Or if you're using pure RSpec, you can use RSpec's built-in include matcher which does hash subset matching. json_spec is most useful in Cucumber.

@mathieujobin
Copy link

I would need something similar, where I want to ignore value for a few keys

right now we are using exclude_keys but this completely ignore the presence of the keys.
I need the key to be present, but do not want to deal with varying values

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

No branches or pull requests

3 participants