Posts Tagged ‘Test-driven development’

This is not the tool itself but the Gradle build GUI showing the tool itself.  Because the gradle build lifecycle is tdd based we get that as a foundation and I am just integrating some tools on top of the gradle android plugin such as code analysis tools robolectric, etc.

How much dev time are we saving?  The typical round trip of compiling the parent project, dx-ing, and installing and compiling the instrumented test and than dx-ing it and installing it can be anywhere from a minute for small project to several minutes per a large project and in the TDD process you would  be doing that perhaps a 100 times on typical coding day. That is over 1 to 2 hours in development time savings. That is not counting the savings of not having to fully mock test an android project and thus it is a substantial amount of development time saved.

To those firms in Chicago looking for Android Developers, I am only 43 minutes from downtown Chicago.

Enhanced by Zemanta

There is a tradition in Java when trying to teach a group to relearn coding patterns or best practices to use the -In-Anger in the title. There are two ways essentially, one is to mock everything so as to be able to use TDD via Junit4 testing in a JVM outside of the Android emulator or android device. The other way is to integrate everything in such a way that one can use roboguice, robotium, and android-mock to instrument test code in the android emulator or android device.

With the introduction of caliper(@googlecode) for benchmarking and vogar(@googlecode) for executing both benchmarking and unit tests via the command line to a Dalvik VM either in the emulator or device that it may once again be speedy and fashionable to do TDD via real unit test code instrumentation.

The title to the article series I have come up with is Agile Android-In-Anger. The anger part is due to the myths that still are out there of what code patterns work in android application development and some performance myths about some of those tools such as dependency injection. The plan is to have some articles up at this next week.

I do expect to fully cover Roboguice, robotium and Android-Mock together.

Enhanced by Zemanta

You might be wondering why I would spend so much time on integrating things via an ANT or Gradle build tool. The whole idea was to be able to do full application testing from beginning to end similar to the way OEMs do framework testing. In other words the developer should be able to run multiple devices and emulators through suite of  tests that include TDD and BDD unit tests among other UI tests and should get back test reports and screen shots.

Now we all know about Monkey UI Exerciser which is a small java api to drive UI testing events. That is not what I am referring to as we need some type of framework.  So what do we need:

-run multiple devices or emulators

-run the application

-be able to interact with ADB

-generates UI events and screenshots

Something has popped up in that I have not noticed it before, its called Monkeyrunner. Its a jython/python api/framework for driving both the android emulators and android devices. Is has a plugin system for using java to extend it and we have an ANT jtyhon task via dbmstools.

With this amount of control to run full set of test suites on an application on multiple emulators/devices why would you choose robolectric over robotium? Sure you get speed of test execution bu than you are sacrificing being able to run a real full tests suite.

But what about not enough Mock objects?  Let me tel you a secret about android mock  objects. A lot of them are not fully documented yet in examples which is why you really should explore android source code as you can find all sorts of useful mock testing objects that the android framework developers use.

Basically this means that the individual tests are using the device or emulator to run along with android-mock and robotium to provide TDD and BDD gets implemented using Instinct during your coding sessions.  Than at the end of the day you are using Monkeyrunner to run a suite of tests as jtyhon/python script that runs a suite of tests on the application across multiple devices and or emulators.

There are enough emulator add-ons provided by SonyEricsson, Samsung, and Motorola that while it does not cover ever device it does allow you cover enough of the android device space among popular handsets to catch most of the bugs that may be device specific.

Evidently Monkeyrunner has been in the SDK since 2.0 but I did not notice it before. Okay, thus I now know why I should be using robotium over robolectric.

Enhanced by Zemanta