Ruby is not a strongly typed language so we sometimes need to check types explicitly. In a ducktyped world this might be less obvious than you might think. In particular, testing code that is testing input types explicitly can be harder than needed. This morning I came to work with a bunch of spec failures in some of our code.

The method being tested looked something like this:

def devour(candy)
  if candy.is_a?(SourCandy)
    SourDevouringEngine.new(candy)
  elsif candy.is_a?(Chocolate)
    ChocolateDevouringEngine.new(candy)
  end
end

If I send in a mock(‘SourCandy’) to the above I get nil back. Most probably not what I meant and surely defying the purpose of testing it.

It’s actually a tricky issue to solve properly. The standard answer you’d get on ruby-talk is to use :respond_to? instead of :is_a? (or the uglier cousin “candy.class == SourCandy”) along with some sassy comment on how ruby is ducktyped yada yada.
I personally feel that is kinda clunky as it relies on SourCandy having some distinct method Chocolate does not have.
Using respond_to?(:fun_fun_fun) also means that I as a developer implicitly state that SourCandy#fun_fun_fun shall always be around and that Chocolate shall never have fun_fun_fun.

That feels wrong too.

So what’s the right way? I don’t have a catch-all answer to that but I think that having to test for type is a slight code smell and an indication that the class structure is not correct.
The code above should be refactored in such a way that I can call devour in the example above directly on the candy object, letting Ruby take care of the distinction. Like so:

def devour(candy)
  candy.devour_engine
end

There are situations where I feel testing for an explicit type is ok. Argument checking in an #initialize method for instance:

class Candy
  def initialize(color, taste)
    raise ArgumentError, "Bacon is not ok." if taste.is_a?(Bacon)
    @color = color
    @taste = taste
  end
end

Another example where it’s sometimes ok is when a method tries to be flexible in input (always good thing) by allowing, say, a String instead of a single-element Array. Like so:

class Dude
  def friends=(persons)
   persons = [persons] if persons.is_a?(Person)
   @friends = persons
  end
end
me = Dude.new
# Both works
me.friends = some_person
me.friends = [some_person, some_persons_brother]

The above is acceptable although I’d prefer using the splat operator to ensure a flat Array: “@friends = [*persons]“.

The take-away here is:

• explicit type checking is almost never needed: check and double check if you really need it
• don’t bend over backwards to accomodate crazy calling patterns, requiring you to typecheck; often it’s simply not worth it and it makes your code harder to read and test
• prefer is_a? to “.class == ‘SomeClass’”