Handling TDD interface changes

Question

I've begun to use TDD. As mentioned in an earlier question the biggest difficulty is handling interface changes. How do you reduce the impact on your test cases as requirements change?

Answer 1

Changing an interface requires updating code that uses that interface. Test code isn't any different from non-test code in this respect. It's unavoidable that tests for that interface will need to change.

Often when an interface changes you find that "too many" tests break, i.e. tests for largely unrelated functionality turn out to depend on that interface. That can be a sign that your tests are overly broad and need refactoring. There are many possible ways this can happen, but here's an example that hopefully shows the general idea as well as a particular case.

For instance if the way to construct an Account object has changed, and this requires updating all or most of your tests for your Order class, something is wrong. Most of your Order unit tests probably don't care about how an account is made, so refactor tests like this:

def test_add_item_to_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    order = Order(acct, shipping_addr)
    item = OrderItem('Purple Widget')
    order.addItem(item)
    self.assertEquals([item], order.items)

to this:

def make_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    return Order(acct, shipping_addr)

def make_order_item(self):
    return OrderItem('Purple Widget')

def test_add_item_to_order(self):
    order = self.make_order()
    item = self.make_order_item()
    order.addItem(item)
    self.assertEquals([item], order.items)

This particular pattern is a Creation Method.

An advantage here is that your test methods for Order are insulated from how Accounts and Addresses are created; if those interfaces change you only have one place to change, rather than every single test that happens to use Accounts and Addresses.

In short: tests are code too, and like all code, sometimes they need refactoring.