Skip to content
This repository

Impossible to test have_json_type with boolean type #7

Closed
mcollina opened this Issue · 7 comments

3 participants

Matteo Collina Brian Ryckbost Steve Richert
Matteo Collina

the have_json_type matcher relies on the ruby type system to mach types. However it's not possible to match booleans, as there isn't a Boolean type.

I think a good extension might provide a :boolean shorcut:

json.should have_json_type(:boolean).at_path("your_path")
Brian Ryckbost
Owner

It should be matching TrueClass, FalseClass and NilClass properly, but a :boolean shortcut might be a good addition.

Steve Richert
Owner

Agreed. I initially wanted to do the very same thing. Hence: http://twitter.com/#!/laserlemon/status/89387369647714305

Steve Richert
Owner

What about allowing have_json_type to accept multiple classes?

last_json.should have_json_type(TrueClass, FalseClass)
Matteo Collina

Well, this doesn't make much sense in term of 'inheritance', because Ruby doesn't have multiple inheritance.
Moreover the syntax it's not immediately readable, as the 'or' between TrueClass and FalseClass isn't explicit.

Maybe a 'have_json_ancestors', eventually including modules might be more flexible and coherent with Ruby itself.
However, the types in JSON objects are 99% booleans, integers, floats, strings, hashes and arrays.
Maybe it's better (and more readable) to have specific matcher for all of these types, plus the generic one.

The above case might became:
last_json.should have_json_boolean

What do you think?

Steve Richert
Owner

Ruby wouldn't need multiple inheritance to have a Boolean class that both TrueClass and FalseClass inherit from. But alas, there simply is no Boolean class. So onward…

I don't follow your have_json_ancestors idea. If you add nil to your list, I think that covers 100% of JSON values. I don't entirely mind your separate matchers idea. I'd have to think on that one.

I disagree that the have_json_type(String, NilClass) syntax isn't readable. In fact, I kind of like it.

Are you interested in fleshing any of this out?

Matteo Collina

Forget that part, I did a mistake and I intended to bring AND matchers, which is clearly not the case.
That's the only problem for me on readability, the fact that OR and AND isn't explicit.

The missing Boolean class it's really a bad design choice of Ruby, so I don't think is good to encourage that kind of thinking. If you expect two different classes in the same place, it's really very, very rare that you won't know what type will be created, and in that case it's like a code smell in your code.

I don't have time this week, but next one I can work on the separate matchers idea if you like it. I will start with the single boolean matcher, so expect a pull request from me at the end of next week.

We might even provide both, it's not a huge amount of code.

Steve Richert
Owner

Closing in favor of #10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.