Develop Reference

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.

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.

What are the differences in the varies Android test case classes?

What are the differences in the varies Android test case classes? That are more than 10 classes in the android.test package that end with "TestCase".
The difference between AcitivtyTestCase and ServiceTestCase is trivial. But what's the difference between ActivityTestCase, ActivityInstrumentationTestCase, and ActivityUnitTestCase?

Typically you do not use the ActivityTestCase class its existence is mostly so that ActivityInstrumentationTestCase (do not use this, it is deprecated), ActivityInstrumentationTestCase2 and ActivityUnitTestCase can inherit useful common functionality from.
From there the difference is mostly down to what sort of testing you want to do. Functional/Integration testing is best done within ActivityInstrumentationTestCase2 while unit testing of an activity is from ActivityUnitTestCase. The difference is mostly down to the methods available in the classes and typically with android being open source any method you want from one that isn't in the other (I have never had this) you can just go and get and probably add yourself.

Using Android Test Framework

Android provides various packages for testing like
AndroidTestCase
ApplicationTestCase
InstrumentationTestCase
ActivityInstrumentationTestCase2 ActivityTestCase
I need to know how to decide which package is best suitable for testing my app. Some info is provided in this link
http://developer.android.com/reference/android/test/package-summary.html
But I need more clarity on this...

TestCase – Plain old JUnit test case. It can be extended to test utility classes that are not tied to the Android framework.
AndroidTestCase – It extends JUnit’s TestCase. It’s a lighter
testing class compared to
ActivityTestCase. It doesn’t need to
launch an activity to run it. Its
getContext() method allows you to get
an injected context if you need one.
Since you can get a context from this
class, you can inflate your UI objects
to test their behaviors.
ActivityInstrumentationTestCase2 – It’s the newer version of ActivityInstrumentationTestCase. ActivityInstrumentationTestCase is deprecated in Android SDK 1.5. It’s a heavier testing class compared to AndroidTestCase. It provides UI and functional testing for a single activity. You can get an injected activity that you are testing on by calling its getActivity() method. The activity being tested is launched and finished before and after each test.
ActivityUnitTestCase – It gives
the tested activity an isolated
environment. When using it to test an
activity, the activity is not attached
to the system. This gives you more
control over what kind of environment
that you want your activity to be
tested in.
ApplicationTestCase – It provides testing for Application classes. It can be used to test the life cycle of an application.
InstrumentationTestRunner – The runner that runs the Android test
cases.
I just found this..Hope this helps for others...If u want more details like when and how to use, see the APIDemos test application in the samples directory within android SDK.

Please see the class hierarchy graph drawn by myself using PowerPoint.
The accepted answer gives enough info in words. I just to make it clear using graph :)
For the InstrumentationTestCase #Zorb asked, it's parent class for ActivityTestCase among others. It enables you to call the getInstrumentation method to get an instance of instrumentation so that you can operate application, activity, and so on.

INTRO
To clarify your question and collocate the classes you are asking for, it is essential BEFORE to divide testing in two categories. JUnit tests (in theory plain Java) and Instrumentation tests (that also are part of the JUnit test package but allow you to test more SDK Android related functionalities).
Traditional JUnit tests isolate a section of code and run a test. Instrumentation tests access instead more inclusively the android components. BUT ALSO THE INSTRUMENTATION TESTS DERIVE FROM THE JUNIT PACKAGE although they are instantiated in the system even before any application code is run and this explain why are slower, furthermore they need an emulator or phone that run the app you are testing to be executed.
(Follow in Bold all the class you mention, but there are others even more used that I will write without without the bold character).
****FIRST PART**(Junit tests)**
A) Junit tests that extend TextCase (are usually faster than Instrumentation, and combine well with Mock framweworks)
AndroidTestCase: It allows to have access to the Context of the Activity you are testing and their resources, it is a base class that extends more specialized subclasses, it is ideal to access databases, filesystem data. You can easily call getContext() and access the Resources without establishing a direct contact with the Activities as will be with Instrumentation tests.
ApplicationTestCase that controls the environment where you text the application, mainly the context and the life cycle. Other really useful extensions of AndroidTestCase allow you to control Loaders,Services,and Content Providers, but for some reason still not any Broadcast receiver that you can call it [indirectly][1] with the method InstrumentationRegistry.getTargetContext() and then instantiating BroadCastReceiver. Also it is really common to use different Mock framework with Junit that is usually faster than InstrumentationTests
-.-.-.-.-.-.-.-.--
****SECOND PART**(Instrumentation tests)**
B) Instrumentation tests, that extend TestCase
Are considered functional tests, focused more to insure that they work well with the user side, the View part of MVC.They are usually slower than the other mentioned category
InstrumentationTestCase is a base class useful to send key events to UI to simulate QWERTY keyboard keys or DPAD buttons,also it launches the Activity that have to be tested, and even Intents
ActivityTestCase Usually is not used alone,it just has common code for the subclasses, but in the case you are not satisfied by the 3 classes that inherit from this one(see below) like a new future component you can use it by the time will not exist a TestCase class dedicated.
ActivityInstrumentationTestCase2 is the most used Instrumentation class to write functional tests, from the constructor is invoked the instance of the Activity to test. Basically you call the activity with getActivity() and you can pratically run any method of that Activity.
ActivityInstrumentationTestCase, is deprecated, and ActivityUnitTestCase that although is under the Instrumentation is more similar to an unit test

I found this tutorial from droidcon 09 to be really informative. Complete with downloadable working source code examples.
Edit: The link seems to be dead, as pointed out in comments.
It walks through creating a Celcius to Fahrenheit temperature converter test-first using ActivityInstrumentationTestCase2, TestCase and AndroidTestCase.