[jpedrosa]

I think it's just wrong to test for the type of the variable, unless it's really needed. Such checking detracts from what you are trying to accomplish and from relying on the exception backtrace to give you a clue of what went wrong when an error occurred. Also relevant is that if you are trying to pass in a new object that should work despite not being a direct descendent of a certain object, by checking for a certain type you restrict the usefulness of the API. Even "mocking" a certain object can be more troublesome then.

That said, whereas many Rubyists can make more use of respond_to?(), I can make a few uses of is_a?() every now and then. They usually make use of more idiomatic Ruby that way than me.

On the Spec/Test side, I hope everyone is testing more functionality than types as I am sure the type checking is just redundant in Ruby. Speaking of redundancies, a famous motto is all you need to follow to keep it cool: "don't repeat yourself".

[Confusion]

Functions only work for a very specific set of input types. On all other inputs, something goes wrong, but that 'something' can take quite a bit of investigating to figure out. Therefore, an assertion that verifies that the input is indeed part of that specific set of input types is valuable: it catches the problem at the earliest possible moment and it pinpoints the exact problem.

[jpedrosa]

For every other type of error, hah, rely on what I said then?