Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Impossible to test have_json_type with boolean type #7

mcollina opened this Issue · 7 comments

3 participants


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")

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


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


What about allowing have_json_type to accept multiple classes?

last_json.should have_json_type(TrueClass, FalseClass)

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?


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?


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.


Closing in favor of #10.

@laserlemon laserlemon closed this
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.