Tuesday, April 23, 2013

How to avoid unstable releases - Introduction

As long as I've been publishing apps for Android, I always managed to break some feature with every update I released. For example, if you happen to use OpenDocument Reader you might have noticed that we release an update on one day (for example, version 2.9) and quickly delivering new updates within the next two or so days (we are at 2.9.2 now). In our case we have two points of failures: Andi, who breaks stuff from time to time by copy and pasting code from one file to another, and me, who 1. mostly simply pulls the changes from Andi and releases an update and 2. breaks stuff by using Andi's code the wrong way.

Anyway, the last few months we kept promising each other not to release yet another update before implementing proper tests... which we didn't, after all (therefore version 2.9 to 2.9.2). But NOW we're totally going to make it! The first step is to implement tests which test only Andi's code. These are not JUnit tests, but we might change that some time in the future.

On my side (Android), we're going to take advantage of everything Android, Google and the ecosystem offers:
  • Monkey
  • StrictMode
  • JUnit tests
  • bug reports (in case everything else fails and a bug sneaks into the app anyway...)