Test first development is now a main feature in projects which use agile techniques. I'm still in awe of seeing complex software being put through its paces by thousands of tests repeatedly, accurately and without a hint of the errors that could be introduced by tired or bored humans. Android supports and encourages this approach as a major factor in helping you create high quality code.  But theres a new twist now - most Android apps are heavily UI driven. Is there anything the framework can do to help us here?

Tutorial: HumbleCalc Skill: Medium Market install Download source

Like all great ideas, the unit testing concept is simple and elegant. Split up your code into small, self contained pieces, and write a parallel set of code, or test harness, to exercise those pieces in isolation. If the tests pass, pull out the harness and you're good to go. Notice this actually encourages good code design, because you write the tests as finely-grained as you need which means you end up with a set of objects which individually do one thing, do it well and thanks to your tests do it correctly. It also recognise that code changes, so you'll know right away if a change you made today broke something written weeks ago.

The kingpin of unit test apps for Java is JUnit. If you use Eclipse for your Android development you'll find it already installed by default. I'd strongly encourage this if you're new to automated testing because of its cleverly integrated hooks. You can easily jump about the source, running individual tests as you need, because Eclipse exposes your tests via menus, context mouse clicks and so on. Of course you can still run them all in "batch" mode, usually via ANT, and when your project hits a certain level thats often the way forward, but right now we'll look at the interactive aspects. Its still JUnit - just with a few sparkles.

To illustrate this, we need an app. I decided to write a basic calculator, so for want of a better name called it HumbleCalc. This app is dull. It throws up a really simple UI, takes input, processes it and displays the result. However, the system is being written under the control of  a JUnit test harness with UI hooks. This differs from the regular way of writing tests, where you have a method separate from the UI which performs the computations and is driven by parameters set up in the test. Here, we still have that background computational method but the way the parameters are sent to it is via the UI itself. As a bonus, you get to see the emulator quickly run through all your tests with the screen whizzing by as if driven by a ghostly hand.

I did warn you! Beauty is not this apps strong point...