Refactoring Day 12 : Break Dependencies

Today’s refactoring is useful if you are trying to introduce unit tests into your code base as testing “seams” are needed to properly mock/isolate areas you don’t wish to test. In this example we have client code that is using a static class to accomplish some work. The problem with this when it comes to unit testing because there is no way to mock the static class from our unit test. To work around this you can apply a wrapper interface around the static to create a seam and break the dependency on the static.

   1: public class AnimalFeedingService
   2: {
   3:     private bool FoodBowlEmpty { get; set; }
   4:  
   5:     public void Feed()
   6:     {
   7:         if (FoodBowlEmpty)
   8:             Feeder.ReplenishFood();
   9:  
  10:         // more code to feed the animal
  11:     }
  12: }
  13:  
  14: public static class Feeder
  15: {
  16:     public static void ReplenishFood()
  17:     {
  18:         // fill up bowl
  19:     }
  20: }

All we did to apply this refactoring was introduce an interface and class that simply calls the underlying static class. So the behavior is still the same, just the manner in which it is invoked has changed. This is good to get a starting point to begin refactoring from and an easy way to add unit tests to your code base.

   1: public class AnimalFeedingService
   2: {
   3:     public IFeederService FeederService { get; set; }
   4:  
   5:     public AnimalFeedingService(IFeederService feederService)
   6:     {
   7:         FeederService = feederService;
   8:     }
   9:  
  10:     private bool FoodBowlEmpty { get; set; }
  11:  
  12:     public void Feed()
  13:     {
  14:         if (FoodBowlEmpty)
  15:             FeederService.ReplenishFood();
  16:  
  17:         // more code to feed the animal
  18:     }
  19: }
  20:  
  21: public interface IFeederService
  22: {
  23:     void ReplenishFood();
  24: }
  25:  
  26: public class FeederService : IFeederService
  27: {
  28:     public void ReplenishFood()
  29:     {
  30:         Feeder.ReplenishFood();
  31:     }
  32: }
  33:  
  34: public static class Feeder
  35: {
  36:     public static void ReplenishFood()
  37:     {
  38:         // fill up bowl
  39:     }
  40: }

We can now mock IFeederService during our unit test via the AnimalFeedingService constructor by passing in a mock of IFeederService. Later we can move the code in the static into FeederService and delete the static class completely once we have some tests in place.

This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Graham

    Watch out for that NRE!

  • http://www.lostechies.com/members/schambers/default.aspx schambers

    I’m not sure I follow. If you refactored in this manner, you would use an IoC framework to inject the dependencies via ctor so you wouldn’t have a NRE on IFeedService.

    Were you referring to somewhere else?

  • Charris

    I guess at least testing for the null ref and throwing?

  • http://www.lostechies.com/members/schambers/default.aspx schambers

    Well once you have this wired up with IoC, you will never have a NRE from IFeedService. If you do then your IoC configuration is incorrect and you have larger problems.

    I personally to check for NRE’s with classes that are registered in IoC. Doesn’t seem like theres a point when a instance will always be provided.