Develop Reference

Why should i mock objects?

I want to some feedback on why I should use mockito when testing my android application and also does anyone have any real examples of mockito would be extremely useful.
Such as a git project with various use cases of mocking android tests.

Mock objects are useful when you want to test part of an application when either the rest of the application isn't written yet, or when you don't want to actually have the side effects that the real code causes (such as writing to a database).

Mocking objects is commonly used it unit testing.
Unit tests are made to assure that the flow of instructions in your code is correct, and the logic is OK, but doing it separately from other classes/objects. Just one class at a time.
So, when your code makes use of any object of other class - you mock it and it behaves like correct object of mocked class, without actually making object of that class.
I suggest you reading about unit testing, injection, mockito.
Hope it helps you to get the idea behing mock.

Android JUnit Test: have some skipped internal methods

I started looking into the Android JUnit Testing, done some researches on the Internet, and enough trials on Eclipse with ADT.
i notice if a test case (i.e. an user-defined method in the junit.framework.TestCase subclass, or specifically, my subclass entends android.test.ActivityInstrumentationTestCase2<T extends android.app.Activity>, according to the guide in the tutorial) is non-public (no matter private or /*package*/), JUnit will give me some errors.
So, how can i have some non-test-case (internal) methods in the Android JUnit testing?
i need those methods for me to help testing the test cases.
As i found from the Internet, Android Junit test is a bit different from the original JUnit test, as some annotations like #Before and #After are not supported in Android. But i guess the way of including non-test-case methods are still the same.
Note: Please noted that i am not going to test some private methods in a class, as many people have been asking.
Thanks for any helps :-)

Robotium with Mockito or Easy Mock

I'm new to Android testing and I`d really appreciate if some of you could help me with that.
I'm using robotium as automation testing framework (so far so good), but I have no idea how I use mockito or Easy Mock to add some mocks to my tests. I'm really stuck with that. Can someone give me some simple example on how to achieve this?
Thanks in advance

Short Answer/opinion
I don't recommend using Mockito for Android unit testing. The Android environment feels too complex to mock. The basic approach for Android unit tests is to run them within the emulator. Thus many of the container classes are already present and need not be mocked.
Long Answer
I also am relatively new to the world of Android unit testing. I have long written server-side unit tests and found Mockito to be one of the best tools around to simplify unit testing. Mockito is very helpful in mocking the behavior of complex objects. This helps to break any dependencies that your code-under-test may have on containers (e.g. servlet container or OSGI container), or on other complex collaborators (e.g. database connection classes).
This sort of mocking works well when your containers/collaborators have well-defined interfaces.
A couple months back, I decided to try Mockito with Android development. I found that Mockito does work if you have at least 1.9.5 and dexmaker. Dexmaker handles runtime byte-code generation for Android's Dalvik VM.
The first thing I tried in my very first test was to mock android.content.Context, and I found that is was HARD. First I tried to mock only the methods that I called directly, but then I found that these called into other methods which had dependencies on application resources, ... Eventually the mocking got so complicated that it defeated the purpose of using Mockito in the first place.
So I gave in and started using the Android unit test helper classes (AndroidTestCase, ActivityUnitTestCase, ...). I was discouraged that I now had to rely on the emulator which meant SLOW test execution. Perhaps Mockito still has a place in this type of test. It might be useful for mocking things like external data sources.
Anyways, this is just my 2 cents.

Mocking android applications like the contacts app using Mockito

I am trying to write functional tests for an android application. The problem is that most functional testing frameworks that I have explored (calabash-android, robotium) have a limitation on the number of activities from different applications that can be tested in the same test. So if in one workflow I need to select some contacts from the android contact picker I cant test that entire flow because the contact picker activity is part of the android contacts application and the framework can't test an activity from my application and the contacts application at the same time.
One possible solution my team thought of was to mock out the call to the contacts activity to return a dummy intent with contact information so that our application workflow can be tested. We are trying to use mockito to achieve this. However I am stuck pretty early on. Here is what I am trying to do
MyActivity mockActivity = mock(MyActivity.class);
when(mockActivity.startActivityForResult(<?>,anyInt())).thenReturn(fakeIntent);
I am not sure what to put in the first parameter in the second line. I have tried Intent.class and android.content.Intent.class however it throws a compile error. If anyone has worked with mocking activities using mockito, some help will be greatly appreciated.
P.S. - If I understand correctly mocking is used more in unit testing than functional testing. So these tests would be more of a hybrid. If anyone has a better suggestion on how to go about these functional tests on android I am all ears.

It's hard to answer this without knowing the signature of your startActivityForResult method, but the general idea is to use any(Xxx.class), where Xxx is the type of the parameter. So either
when(mockActivity.startActivityForResult(any(Xxx.class),anyInt())).thenReturn(fakeIntent);
or the (kind of equivalent)
doReturn(fakeIntent).when(mockActivity).startActivityForResult(any(Xxx.class),anyInt());

The issue is that you cannot really "mock" (actually "spy") on the activity you're testing since it is created out of your control by Android's instrumentation code. In a unit-test environment where you would have control, you could follow the mock(MyActivity.class) or spy(myActivityInstance) path (spy would actually be better because you could re-use most of the activity's original implementation), but here not.
The only solution I found for this dilemma was to move certain functionality out of the activity into utility classes, ideally utilizing roboguice for that (#ContextSingletons can be used to process activity results). Then, in your test project, you would create your own test guice injector, set that as base application injector before you call getActivity() for the first time and then let the activity work on your mocked utility class.
I outlined the complete process here.

Is it possible to create a stub of android.os.Bundle for testing under JVM?

As the title says, I want to know, if possible, how can I create a stub from Bundle to run at JVM (so not Dalvik). Since its part of android.os package, may be that is related to that impossibility.
My point is due to the fact that I want to use a mocking framework, which run at JVM, to test the Activity.onCreate() method.
I've already found this link but it seems they use a stripped custom android.jar since its rather experimental and unproven (yet I could not reproduce even with their jar, maybe I need some sleep).
If there is another alternative to mock testing this, any insights will as always be appreciated.
Thanks.

I've been successfully writing unit tests on the java jvm for classes that interact with android.jar classes. I use Powermock to mock out all android classes (like Bundle).
This link talks about using a version of the android jar that does not throw the "stub" exception on the java jvm. I have not needed to use a different version of the android jar. Using Powermock I've been able to successfully mock out anything I need to. For me this unit testing technique is not experimental.
Having said that - the unit tests for classes that extend activities, fragments, etc. become very much mock heavy. I feel it's good to move as much logic as you can into pojo classes, keeping your android extended classes as thin as possible. You can decide then if you feel it's worth isolation junit testing the android extended classes. It can certainly be done if you wish. You can also consider an integration testing framework like the one provided by Android or Robotium to test your android extended classes and their lifecycles.