{"id":452,"date":"2011-06-05T00:19:00","date_gmt":"2011-06-05T00:19:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/android-dependency-injection-and-testing-libraries.html"},"modified":"2012-10-21T19:51:43","modified_gmt":"2012-10-21T19:51:43","slug":"android-dependency-injection-testing","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/06\/android-dependency-injection-testing.html","title":{"rendered":"Android Dependency Injection and Testing Libraries"},"content":{"rendered":"
Anything and everything that makes life easier to develop for Android should be looked into. There are a couple of libraries that make testing easier, increase the modularity of your code, and provide already created mock objects: <\/p>\n
    \n
  1. RoboGuice<\/a> – This is an adaption of Google\u2019s dependency injection library but for Android<\/li>\n
  2. Robolectric<\/a> -This is a testing framework\/platform which works to remove the need for constant mocking of Android objects.  It also works with RoboGuice.<\/li>\n<\/ol>\n

    I can\u2019t begin to thank the guy that first introduced me to dependency injection enough. Coming from a C++ world, where objects can\u2019t describe themselves and there is no reflection unless the developer purposefully implements it himself, to a more modern language I often created my own static factories to simulate the @inject pattern. But why reinvent the wheel each and every time if an object can describe itself perfectly to the virtual machine?<\/p>\n

    If you\u2019ve never seen Dependency Injection (DI) before look at the \u201csimple example\u201d<\/a> RoboGuice provides on their webpage. At first glance it might seem like a fancy way to clean up the code so that maintainers could focus on just the specifics of the actions within each method. That is a side benefit (a really nice one at that) but only a side benefit. The example does not demonstrate the true power of such a framework in testing and asserting bug-free code.<\/p>\n

    Without DI in your code base<\/h3>\n

    Let\u2019s take a look at a contrived example of what sort of pain points DI can help conquer and alleviate. Suppose that I have a method which needs some sort of widget that takes user input. How can I test such a method without requiring someone to step through a script (as in written instructions) wherein they manually enter all the different combinations which could result in a real world scenario? That\u2019s expensive and time consuming. I\u2019m not even going to mention the human factor for mistakes (like skipping a test by accident). Oops, I just did (see? So easy to make mistakes!)<\/p>\n

    If there was a way to instantiate mock constructs without having the parent object\u2019s constructor  grow to 20 arguments long I\u2019d love to jump all over it. Thinking back to design patterns 101, factory objects<\/a> provide a means for decoupling object creation logic from object instantiation. Using a static factory object I could insert a test version whenever I wanted. Take a look:

    <\/div> <\/div><\/p>\n
    public abstract class WidgetBase implements IWidget{\r\n   protected ISomeObject mSomeObject;\r\n\r\n   public WidgetBase(ISomeObject _obj){\r\n      mSomeObject = _obj;\r\n   }\r\n}\r\n\r\npublic AlertWidgetFactory{\r\n   static private WidgetBase mTest = null;\r\n   static private boolean mTestFlag = false;\r\n   static WidgetBase create(ISomeObject _obj){\r\n      if(mTestFlag){\r\n         return mTest;\r\n      }\r\n      return new AlertWidget(_obj);\r\n   }\r\n\r\n   static void setTest(WidgetBase _testWidget){\r\n      mTest = _testWidget;\r\n   }\r\n\r\n   static void setTestFlag(boolean _flag){\r\n      mTestFlag = _false;\r\n   }\r\n}\r\n<\/pre>\n
    Now when I get down to testing my code I can automate everything.  During the \u201csetUp\u201d phase of my JUnit unit test I can substitute in some  mocked version of \u201cWidgetBase\u201d to return many possible user entries. See how easy to test it makes the following code:<\/p>\n
    public void someMethod(String _value){\r\n    if(_value == \"\"){\r\n      ISomeObject foo = new SomeValueAssigner( _value );\r\n      IWidget alert = AlertWidgetFactory.create(foo);\r\n   }\r\n   \/\/more code...\r\n}\r\n<\/pre>\n
    Of course, if I have a different class type I want to produce from a  factory, I\u2019m going to have to code up a factory just for that object.   (In C++ I\u2019d just template it and have but a single class for a factory. Sometimes templates are a good<\/i> thing, no? Take that generics!).<\/p>\n
    With DI in your code<\/h3>\n
    Some might be screaming at me for not using a plain interface instead  of an abstract class. There was a point to that. Interfaces can\u2019t  describe the constructor and I wanted my object to take parameters in  the constructor. But why?<\/p>\n
    First have a closer look at the code above. Did you notice up above  that I\u2019ve got a hard-coded dependency in \u201cSomeValueAssigner?\u201d I\u2019m not  truly able to unit test the \u201csomeMethod\u201d function as I can\u2019t remove the  interdependencies without first creating a factory method for that too!  Oh the humanity. How many factory objects are we going to have to  create just to test a decently sized code base? Each time I want a new  object I\u2019ll potentially have to create for it an interface, abstract  base class and\/or a factory object. I might also need to add a new  method to the factory object for each different constructor it has.<\/p>\n
    I don\u2019t need to say it but that\u2019s a lot of work. Actually it\u2019s too  much work even for the engineers at Google.  This is why they came up  with Guice<\/a> in the  first place. DI solves a lot of headaches and saves on needing to  reinvent the wheel time after time with some limitations (see InjectionPoints<\/a>  on constructor arguments). It isn\u2019t a replacement for your standard  design patterns and doesn\u2019t let you avoid passing arguments into a  constructor. RoboGuice is just another tool in your toolset (a very  powerful and handy tool).<\/p>\n
    Avoiding the Emulation Stage<\/h3>\n
    Wouldn\u2019t you know it but testing UI components is hard work. Not  only do we need to look at the thing in the first place just to see if  all the shapes\/sizes\/colors are displaying correctly but we also need to  make sure it does what it\u2019s supposed to do. Then there\u2019s the waiting  period while the emulated Android device warms up. Quoting from  Robolectric\u2019s website:<\/p>\n
    \n
    Running tests on an Android emulator or device is slow!  Building, deploying, and launching the app often takes a minute or more.  That\u2019s no way to do TDD. There must be a better way.<\/p>\n<\/blockquote>\n
    I couldn\u2019t agree more. Waiting on the emulator to compile and load the application for a small, tiny fix is painful.
    \nRobolectric lets you iterate faster.  Iterating quickly leads to  better design. Better design leads to less maintenance problems. Less  maintenance problems leads to more time to add new features or refine  functionality. All these things lead to a better product experience for  the end user.
    \nThat is tremendously beneficial to your bottom line. Even though  this section is very short it\u2019s nearly inversely proportional to the  amount of time it will save you.<\/p>\n
    Conclusions<\/h3>\n
    RoboGuice let\u2019s you test more easily and adds another tool\/idiom to  help decouple your code. Robolectric let\u2019s you test faster. Put them  together and you get an environment where you are working more  efficiently and productively. These are two libraries you shouldn\u2019t be  without.<\/p>\n
    Reference: <\/i><\/strong>Android: Libraries you should be using<\/a> from our JCG partner<\/a> at the Statically Typed blog<\/a>.<\/p>\n
    Related Articles :<\/i><\/strong><\/div>\n