Generally, when a class has a dependency it is preferred to use
Inversion of Control. The popular methods for specifying the dependency are
setter and
constructor injection. Dependency Injection is one of my favorite patterns because it facilitates loosely coupled code that is easily testable. However, recently I found an alternative solution that can be used when DI is used solely for testing.
Let's start with a class** (CellPhone) containing a dependency (SimCard):
class CellPhone
def initialize
@sim_card = SimCard.new
end
def save_number(number)
@sim_card.save_number(number)
end
def include_number?(number)
@sim_card.include_number?(number)
end
end
In this example it is not clear how you could test the CellPhone class without depending on the SimCard class. This can create problems such as the SimCard class raising errors like SimCardFullError when you are actually only trying to test the CellPhone class. A simple solution is to introduce Constructor Injection to decouple the SimCard class.
class CellPhone
def initialize(sim_card)
@sim_card = sim_card
end
def save_number(number)
@sim_card.save_number(number)
end
def include_number?(number)
@sim_card.include_number?(number)
end
end
This solution does work; however, you now need to create an instance of the SimCard class before you can create an instance of the CellPhone class. In the case of this example additional work has been created because the CellPhone never needs to use different types of SimCards except when testing.
There is an alternative solution that allows you to stub the behavior of a class without stubbing the entire class. This alternative solution is available because Ruby allows you to re-open classes. To see how this works we will need a test.
class CellPhoneTest < Test::Unit::TestCase
def test_save_number
phone = CellPhone.new.save_number('555-1212')
assert phone.include_number?('555-1212')
end
end
This test will pass with the first implementation assuming the SimCard class does not cause a problem. The change to test using the second implementation is straightforward enough that I don't feel it's necessary to demonstrate. However, what I do find interesting is how I can test CellPhone in isolation without changing the first implementation. The way to achieve this is to re-open the class within the test and alter the behavior of the class.
class CellPhoneTest < Test::Unit::TestCase
def setup
class << SimCard
alias :save_old :save_number
alias :include_old :include_number?
def save_number(number)
end
def include_number?(number)
true
end
end
end
def teardown
class << SimCard
alias :save_number :save_old
alias :include_number? :include_old
end
end
def test_save_number
phone = CellPhone.new.save_number('555-1212')
assert phone.include_number?('555-1212')
end
end
As you can see in the example the CellPhone class tests are no longer brittle despite the dependency on SimCard.
It's important to note that for our example it is assumed that CellPhone will always depend on the SimCard class. If it needed to depend on different types of SimCards then Constructor Injection would be necessary anyway.
While our solution does work it's not entirely elegant. Luckily,
James Mead pointed me at
Mocha, a library that facilitates this type of behavior switching. Using Stubba the test becomes much cleaner.
require 'stubba'
class CellPhoneTest < Test::Unit::TestCase
def test_save_number
SimCard.stubs(:new).returns(stub_everything(:include_number? => true))
phone = CellPhone.new.save_number('555-1212')
assert phone.include_number?('555-1212')
end
end
For more information check out the
documentation for Mocha.
** Of course, the real class def would be
class CellPhone
extend Forwardable
def_delegators :@sim_card, :save_number, :include_number?
def initialize
@sim_card = SimCard.new
end
end
