Tuesday, December 15, 2009

unit testing android

Trying out ScribeFire for blogging, looks decent (and is a plugin for FireFox so cross-platform). So far looks nice.

Looking at Diego Torres Milano’s blog: Android: Testing on the Android platform – Unit tests – obviously this is over a year old and out of date (1.0 was current then). When creating a project now the ADT plugin allows you to create a parallel test project at the same time or a later time. I somehow picked out the right way to run a simple unit test once, but it doesn’t seem to want to run again. And when running as an “Android unit test” it actually opens an emulator in order to do unit tests?!? I can kind of understand that but it seems unnecessary for unit testing. For now, writing this off as too out of date.

Continuing with Diego Torres Milano’s blog: Android: Testing on the Android platform – ApiDemos tests. I followed the directions – I think – but when I pasted the source files into the test project they got pasted in the original package locations (e.g. com.example.android.apis not com.example.android.apis.test), which seemed to cause no problems. Linking the test project to the original was as advertised. Directions are ambiguous as to which manifest file to copy to the test project – get the one from the test directory. I was able to run the ApiDemosTests package as an Android Junit Test and see it actually go; did not have to do anything in the emulator, and the results show up in the JUnit widget in eclipse. I could see things happening in the emulator, so I guess it makes sense to have it up :-) I also tried running them from the Dev Tools or from adb and that worked as specified. Good to know.

Diego didn’t label this post so I almost missed it: Diego Torres Milano’s blog: Android: Testing on the Android platform – Creating tests; and this is a pretty good starting point. Got my test suite runner and a unit test shell set up, going to have to stop here for now.

So it’s great to see that this guy is also a bit frustrated with the docs (mostly, lack thereof) on testing; like emulator skins, tests are provided for you to reverse engineer, but not explained anywhere. I guess working tests are a little better than actual documentation which can get out of date fast. Diego seems to have a good understanding of JUnit and testing before coming to Android, which helps him. I don’t have that, but my brother does; this seems like an area that’s ripe for exploration and making a name by explaining. Heck, it would probably be worthwhile just to provide links to selected relevant posts by Diego putting them in an order that would be helpful to a beginner learning this stuff.

At my last meetup I told people that after you create an AVD, the tool doesn’t provide you any way to change its configuration. This is true, but you can edit the files that specify the config pretty easily – they aren’t even XML. The question is whether the emulator image itself (in the user’s .android directory) is modified at all according to config. I suspect the answer is “no.” At least, I tried changing the skin on an AVD (edit config.ini within the .avd definition) with no adverse consequences. But that’s superficial; other elements that refer to actual capabilities might need a matching setting inside the emulator image. I don’t know yet.

[Via http://sosiouxme.wordpress.com]

No comments:

Post a Comment