If you want to test any class that imports/uses an Android class, you have to run that test in the emulator, and Android has a nice Test harness to test your Activities and such in an Android App.
But how do you test classes that use Android class, but isn't an Android App, but instead a Library/Framework to use in an Android App. The Library/Framework is a standalone project, but it uses Android classes. How do I write Unit Tests for those classes I can't extend the standard Android TestCase classes because my classes aren't Activities, Services, or any of that.
For other Java classes, keep in mind that Android JUnit is built on top of regular JUnit, so you can use regular framework for testing.
These are none of those four. I guess I didn't describe it well. These are plain classes, but you cannot use regular framework for testing because the classes I am testing does import Android classes in them. I am building a library/tool developers can use when developing their applications. Since they import Android classes and use them, then regular JUnit framework would throw an error because the android.jar file in the classpath just has stubs in them, no real code.
Yeah, but my app isn't an android app, but a library of classes you can use on Android to simplify SQLite database access. And I need to write tests for that.
If you subclass TestCase you will always get a Stub exception because the android.jar file only has stubs, no actual implementation and code. That code is only provided on the emulator or a real device. And creating an Activity without needing any UI just so you can test some code seems so Cludgy to me. But Android overall, is a little bit cludgy anyway. (opinion of course)
Well if you are writing code that depends on android.* code, you must run it on an Android device. That is because android.* classes depend on rest of the stack on the system. And to run it, it should be an Android application. So, one option is to create an application that is driving your library on the device. Other option is not to use android.* code and make your library work off of standard SQLite classes in witch case you can test outside Android.
I have found that I have to very carefully separate the "controller" and "view" code (which depends on the Android Framework) from the "model" code (which doesn't). I can then write standard JUnit unit tests against the model classes, and have them running as part of the test phase of a Maven build. In order to support this I have had to abstract a few things:
* I have an interface that will yield a file. For the code running on Android I have a class that yields a file on the sdcard. For the unit test I have a class that yields a file in the target directory.
* I have had to also factor out the logging so that on Android I use the Android logger and in the unit tests I use commons logging with Log4J (my next experiment will be if i can use commons logging on Android itself which should make logging easier).
I'm sure I will find more issues as I got further one. Essentially, anyplace in my model classes where I think I might need to use an Android class I will have to create an interface instead and supply an alternate implementation for the unit tests.
Yeah, I will have to run the tests on the emulator. The library is integral to Android. It isn't just an abstraction above SQLLite, but SQLLite and Android.
0
