Develop Reference

Should I use Android Instrumentation to write unit test?

I have read some articles about unit testing in Android including the official documentations and wrote some demos, it is complicated and slow because it must run on a device or emulator. Should I continue using it or find another option?

Usually a good test should run on the target device. Thats why my answer is: yes you should continue using it. If you test on an emulator or something like that there could be some little differences that would cause some different behaviour than on the real device (espacially if you use some hardware components).
If you use a real device there is also the side benefit that the test runs faster than on the emulator.

You're looking for Robolectric.
Robolectric is a unit test framework that de-fangs the Android SDK jar so you can test-drive the development of your Android app. Tests run inside the JVM on your workstation in seconds.
It is not complete yet (e.g. Support Library Action Bar is not supported) but it will save you a lot of time anyway. Besides you can add what's missing by developing shadows yourself.

My alternative looks like this:
I have refactored my android app into
app (gui using the libs),
android-independant-lib (service-interfaces, dto-s, businesslogic without database bindings)
android-dependent-lib (android specific implementation of the of the service-interfaces and database binding)
for the android-independant-lib i have created "normal" junit-tests
for the android-specific parts i currently have no automatted tests.

How to retroactively add tests to a code base?

Suppose you are tasked with adding a testing framework to an existing code base that has very very little unit testing coverage. The code base isn't insanely large yet, however, it does have areas where it's not super clean, or not very OOP or testable.
I've read a couple of good answers:
Adding unit tests to legacy code
How to approach unit testing in a large project
Best Option for Retrospective application of TDD into C# codebase
But the project I'm working on is an Android app, so it's slightly different (given lots more UI components).
I have some questions that all relate to the same issue:
What's the best way to do go back and put a bunch of tests in place?
How do I prioritize which parts to test first?
do I start with areas where it's getting called a lot (and is there a tool for code analysis like this)?
or do I go back and look at classes which in the past have had the most number of bugs?
Should I write integration tests first (given this is an Android app and also integration tests may prevent broken unit tests/refactorings) and then work in the unit tests?
Sorry for all the questions, just really looking for a good approach, more specifically geared towards retrospectively testing an Android app.
P.S. I'm curious if people know of good tools they can use for code analysis that can help bring to attention the areas in a code base in which unit testing would be most helpful.

Usually when starting with unit testing on an existing application you would want to do it iteratively - you probably do not have the time or the man power for a big upfront investment and so you want to add unit tests as part of the required work:
Write unt tests When adding a new feature - or better yet use TDD
When fixing a bug - write unit test(s) that fails de to the bug before fixing it
When refactoring old code wriute unit tests to make sure no regression bus were introduced
Id the whole team follow the three steps above in a matter of weeks you should have good coverage for the code you've been changing - depending on the size of the project.

I don't have an Android-specific answer. I hope someone comes along and adds a good one. Meanwhile: write acceptance (integration) tests for your most important features (from your product owner's point of view, not from some tool's). You'll get the most coverage for your effort, and be the most likely to prevent bugs that customers care about. Don't worry so much about unit tests; those are for details.
[That's the answer given in the third post you cite, but we're still waiting for that Android-savvy answer so let's not call this a duplicate yet.]
Do write acceptance tests and, as necessary, unit tests for new features, and write unit tests when fixing bugs.
Regarding how to find areas of the code that need tests, the first thing to do is measure code coverage. (You can do that in the Android SDK with ant emma debug install test.) Obviously code with no coverage needs tests.

Android unit test case automation: Robolectric library vs Android Testing framework

Wondering which one is the better choice to write unit test cases for android apps and libraries: Using Robolectric library or sticking with Android Testing framework. I want to run test suite at commandline and want it be independent of need of configuring emulator or letting a device attached with build machine. Does anyone of you run a comparative analysis on both of these or something better? Your experiences will be great help me to decide on the better solution.

I use a tiered system, where I prefer earlier tiers where possible:
Pure unit tests. I try to make as much code as possible fully independent of Android APIs, and then use "pure" unit tests which can run on any JVM. These tests are the fastest, and it helps keep code that has no need to be Android-specific portable.
Robolectric-supported unit tests. Where my code has only small dependencies on Android APIs, that can be satisfied by Robolectric shadows, I test it with Robolectric. There is a little more setup time for Robolectric compared to pure tests, but it's still faster than starting/running on an emulator.
Android framework tests. Where Robolectric doesn't cut it - either because the shadows don't exist, or because I'm heavily using Android APIs (and therefore want to test against the Real Thing) - I write test that run on the emulator/device with the default framework.
The point of the tiers is to keep things as simple as possible, which keeps the full suite faster and helps promote cleaner code.

I worked on both, what i found is :-
1) Robolectric do not support API 19, it's mention in its document -
http://robolectric.org/eclipse-quick-start/. It's a great
disadvantage of it.
2) Robolectric run on JVM not on DVM. So we can not
detect that on that particular time GPS is enable in device or not
etc. We can only pass our pre-decided value for it.
3) Code writing in Robolectric is complex than junit specially for
fragment there are lot of complexity and issues.
4) Robolectric needs external jar and configuration and for junit test
we do not need any external library.
5) Robolectric is faster because it runs on JVM but this have
disadvantage too, we can not see UI on our device, what screen code
is executing.
For Android, i like jUnit test.

Testing android applications

I'm new to testing.I've developed a application,now i need to test.I googled about testing for some time,learnt ,what different types of testing are there in general.I wrote few test cases.
Three things,i would like to know,
Is there any different types of testing for android,if yes,can you give me some links which could help me to refer.
How do generally a android user test his apps,Will he uses test frame works or generally write test cases and testing that on real phone to see how they are performing.
Is there any sample test cases written document which will give me some basic idea.

For integration testing I use Robotium. It is a nice convenient layer on top of the build in instrumentation testing. These Tests need to be running in an emulator or on a real device. It is recommended in both cases to have an extra test project (producing an additional APK) that depends on the project under test.
Personally I like to partition my app so I have one or more libraries that do not depend on Android specific classes and can therefore be tested in a regular JVM using JUnit.
There is a third way to test and that is by mocking the android classes and have the tests run in a JVM. I have not yet used it but I hear Roboelectric is a framework that allows for this kind of testing.

Android Monkey tool can be a handy little tool. I find it handy the pseudo random fashion is handy for generating unusual use cases.
http://developer.android.com/guide/developing/tools/monkey.html

How to do Cucumber Android integration testing?

I'm trying to set up continuous integration with an Android project and Cucumber.
The idea is to write tests in Cucumber and run the tests on my Android build via Cuke4Duke and NativeDriver for Android.
When I have this running, I plan to use Maven and a Jenkins server to automate the testing, so it is run every time i commit to the Subversion repo.
Has this been done before? Is there a good guide somewhere? Or is it a bad idea to do it this way?

We're doing exactly what you're planning to do with Maven, Jenkins, and Git. The missing ingredient is the android/cucumber integration from lesspainful.com.

I don't think that what you've planned is a bad idea. But I don't know of anyone that's doing Android CI with that particular setup.
You may also want to take a look at Robotium, it's like Selenium for Android and offers a very rich DSL that will help out with your cuke4duke step implementations.

In my company we use a little different setup (but probably you will have to solve similar challenges): Jenkins + Jenkins Android Plugin + Robotium + Ant. We find out that ant is hard to maintain when you try to use it to something more complicated then simple build and we are rewriting our scripts to gradle.
It works quite well, however you should be aware of two potential problems:
1. emulator is slow (even on fast server) - you can consider attaching physical device to your server.
2. you probably have to setup lock (or use only one executor) for emulator since using multiple emulator instance is hard/tricky.

What we have done is write an test instrumentation engine above Robotium. This engine is mainly a state machine reading keywords from a text file and converting them into Robotium API calls. We did initially notice that inputs and outputs were the same: user taps on the screen, a new screen is displayed or new text is displayed.
That allows us to implement keyword test driven but it runs on the device so not remotely.
It is 20% of effort to get 80% of the benefit: easy to write/add new tests that are readable by anybody. Of course there are limitations but our goal was achieved.
Cheers
Ch