Posted by Robert van Loghem around lunchtime: March 9th, 2011
Since a couple of months I’ve been developing mobile applications, some are for the business at home (girlfriend-shopping-list app that actually works and augmented reality garden iPad app) and some are for work. I have experienced that TDD and Continuous testing (Test Driven Development) is a way of working that leads to fewer bugs and regression problems and better design in my software, it’s my preferred way of programming, not testing.
And to start off, here’s how I benefit from doing TDD:
- Robust
- Better code design, no really!
- Find regression problems early on
and you can read more on TDD and Continuous testing here.
The thing is, writing a mobile app takes about 20% of the time it would take me to write a web+client+server based app. Which of-course is really nice, because I can write lots of apps. It also means that whenever i need to fix a bug or add new functionality, I need to have developed it in a TDD fashion, otherwise i cannot guarantee reliability. So let me explain why…
Previous experience
The last complex software piece I’ve worked on is a product called Deployit, which can deploy java applications to application servers, not just one, but many different type of servers and the deploy part is encapsulated in a piece called a plugin. For every plugin we have written lots and lots of tests and boy do they prove to be a lifesaver.
As a developer I’m not just working on a single plugin, I’m working on the entire product (partly, because we are a small team and i like to do so), that means that for a single week I’m adding new deployment logic to plugin A and next week fixing a bug in plugin B. I’m a good programmer with a good memory but working on so many plugins and quickly fixing problems or adding functionality is hard. I have to context switch between intricacies of plugin D and the complexity of plugin W, I am bound to make a mistake or two, which will delay the release or upset users because functionality that used to work is now broken.
So how does this compare with mobile apps? It’s simple, plugins, resemble for me, apps. In the mobile world, you are bound to work on multiple apps in a short amount of time, that means, you need help to keep those apps stable when you are working on them.
Translation of TDD+Continuous testing to mobile development
Did you ever update an app that you worked on 2 months ago and broke per accident some old functionality? Then you must have seen what happened with your user ratings, it went down, right? People expect functionality that have always worked to still keep working, otherwise you will get 1-star or worse, it gets deleted! New functionality can have some bugs, because it is new, existing functionality should just work, there is no excuse for it to not do so.
Unless your brain can keep track of what the code of every app that you might work on is doing, which I don’t think it can, if it would you would work at NASA on “Space Bus 3.0″. That is where your automated tests come in, they really help you, make a fix and guaranteeing that your old functionality does not break.
It also helps you make new functionality more robust, don’t just test the happy flow, also test the monkey flow, input some weird data, trigger some weird touch-events, see if you can make your app crash, and do this automated. Your app becomes much more robust and your users will love you for it.
What is next…
The above words are all fine, but how do we actually do this ? In the next couple of blog posts I will go into technical detail how to do;
1. Unit testing (cheap testing at code level, OCUnit, JUnit)
2. Continuous Integration (using Jenkins)
3. UI testing (not so cheap testing at the UI level, Automation API’s, mock framework)
and do this for iOS and Android platforms.
