Comments on: Android Functional Testing vs Dependency Injection

By: Maks

Maks — Wed, 11 Jan 2012 00:05:46 +0000

Thanks for the great pattern, its a perfect fit for use in simple android apps and exactly what I was after without going the heavy weight route of using roboguice.

By: Dan

Dan — Tue, 22 Nov 2011 12:16:29 +0000

This post just blew my mind. As a newb Android developer (two months) I have been looking for a good way to do this. This is awesome!

Thanks for the wonderful post!

By: Tom

Tom — Wed, 19 Oct 2011 16:36:31 +0000

You can actually make it work with instance rather than static fields if the test uses getInstrumentation().getTargetContext().getApplicationContext() to get a reference to the application object.

By: Sam

Sam — Wed, 07 Sep 2011 03:30:54 +0000

I use a similar pattern although I initialise the service to the default impl as required via null check and just use the setter in the tests.
However, my issue is that my fake service is providing an alternative data set which cannot be browsed via the running app (when conceiving a new test) without the app knowing about the fake class.. which it doesn’t because it resides in the test application, not the application. Do you know how to run the android app in “test mode” .. ie, as you would see it when the unit tests are run against the fake service?

By: Tom Leach

Tom Leach — Sun, 17 Apr 2011 18:25:01 +0000

Great pattern! Having come from an enterprise background and being used to making heavy use of DI I was a bit dismayed to find out how coupled android application classes seem to be to the underlying API via inheritance.

I had considered roboguice as a possibility but I don’t like the way it makes you use their testing framework classes.

Using a centralised service locator seems like a good pragmatic alternative. I’ll give it a go.

By: Yoshihiro

Yoshihiro — Thu, 13 Jan 2011 06:07:07 +0000

Hi.

I tried to inject to Activity by using guice2.0_no_AOP.I didn’t use roboguice.

I could inject by field static injection like following.

//MyActivity
public class MyActivity …
@Inject static private Service service;

//in guice Module
Protected void configure() {
bind(Service.class).to(ServiceImpl.class);
requestStaticInjection(MyActivity.class);
}

But when I write test, using this method let me write another Module for test and make injector instance in testing code.

Do you think which one is easier?

By: David Laing

David Laing — Mon, 03 Jan 2011 20:51:08 +0000

Jason,

Amazing – a pattern that usually gets me in trouble is exactly right for a simple Android app.

Thanks for bringing it to my attention (again)

David

By: Jason

Jason — Tue, 13 Jul 2010 11:48:25 +0000

Hi Miguel,

Thanks for the kind feedback. Re: testing preferences, you are correct that if you use ActivityInstrumentationTestCase2 you get a real context and changes to the preferences will persist. Actually in my example I use an interface (ISettings) in between the preferences and my activity under test. In my case this is to make it easy for me to fake different preferences without changing the underlying persistent data. You could extend this idea to allow settings to be changed via the ISettings interface, and test your activity makes the intended updates in that way.

By: Miguel

Miguel — Tue, 13 Jul 2010 10:47:38 +0000

Hi,

have you tested any Activity that made changes on the preferences? In my tests, the changes were persistent, which is something I obviously don’t want. I’m still new to android world, but my guess is that getContext() returns the real context of the application rather than a mock/fake one.

Thanks a lot for the android related posts, they are well written and formative. I added you to my reader.

By: Jason

Jason — Wed, 30 Jun 2010 00:08:48 +0000

Hi Dom,

Thanks for the tip: I’ll have to check out android-mock.