Android Unit Testing with Robolectric

The last weeks I had the chance to dive deeper into unit testing of an Android application. The solution we are using is Robolectric. It is an interesting and promising framework since it does not need an emulator but just runs as standard junit test. The tests we have been able to write and run with it are great. You can even create an instance of an activity, inflate the UI from layout files and check the state of single views. Or you can send a broadcast intent and check if it has been received.

Of course, Robolectric does not create a real UI for the tests. The way Robolectric allows testing of Android applications, works by intercepting the creation of instances of Android classes and provides some kind of proxy objects for them (so called Shadows). This way, the Robolectric developers have been able to rewrite parts of the platform’s behaviour, emulate the logic of a lot of classes and internally keep track of the state of the objects.

While this allows for efficient unit and integration testing without starting an emulator, it is clear that Robolectric tests do not replace testing on real Android devices or emulators with different OS versions. There are a few reasons for this:

  • The code just emulates the logic the Robolectric developers have implemented. For the most common use cases, this works well, but you find missing/limited functionality quite quickly. This will improve over time. Nevertheless, one has to be aware of the fact, that not the real Android classes are used and the behaviour can be different from the Robolectric classes.
  • The Robolectric framework does not emulate the real lifetime of an whole application. E.g. it will not start an activity or a service on its own. Also, it does not emulate the lifecycle of activities. This is by purpose, since it anyway is meant only for testing single units of the app. Of course, you can check which intent is being sent from an activity, which allows for testing the correct behaviour.
  • There are also general limits to this concept. E.g. when your app is not based on the standard View classes, but uses OpenGL, this can not be tested with Robolectric. I would say, all cases where real hardware is involved, can not be tested.

In summary, Robolectric allows efficient testing of a lot of use cases of an Android application. It is certainly not enough to make sure it will run on all devices. But it already provides a way to cover a lot of use cases of standard Android applications and make sure that the single components of your app behave correctly.

One thing that is heavily missing is better documentation, though. Without having the source code of Robolectric available and checking how it is implemented or looking at the unit tests of Robolectric itself, I would have not been able to figure out how some things are expected to work.
Therefore, I will try to collect here some howtos and hints for Robolectric in the coming weeks.

My other articles about Robolectric might also be interesting for you.

My summary of the Android Open Conference 2011

After arriving back in Germany from the O’Reilly Android Open Conference in San Francisco, I want to summarize my conclusions and general impressions.

Being in San Francisco and attending the conference was very inspiring. The keynotes have given a great overview what is possibly coming in the future and having Tim O’Reilly speaking about leveraging the openness of the Android platform was very motivating. As well as seeing what people are doing with standard hardware, like the NASA with Nexus S based mini satellites is crazy.

What was also great, was to „feel“ what makes the bay area so special in terms of innovations: ways are short, it is easy to connect with people from great companies ( be it startups or established ones), you get first class information from first hand, and people are very open to try out new things.

My summary of the Android Open Conference 2011 weiterlesen

Interesting Google IO 2011 Sessions

Since I finally found the opportunity to have a look at some Google IO 2011 sessions, here are some links to sessions I can recommend:

Android Development Tools:
Shows some neat tips & tricks for using new (and old) features of the ADT plugin for Eclipse

Android Protips: Advanced Topics for Expert Android App Developers
Provides a lot of great tips and some patterns for common problems, e.g. keeping backward compatibility while still using new features, doing battery efficient data updates, etc.

Memory management for Android Apps
Background information about the garbage collector, memory management in the Dalvik VM and how to find memory problems by using the Eclipse Memory Analyzer

Building Aggressively Compatible Android Games
A good high-level summary of how to make apps compatible for many devices.

Why and How to Document your Software Architecture

Coding the Architecture provides a very nice slide set giving a very good high level overview of why and how to document your software architecture in a practical way. As I wrote, it is a slide set and therefore only provides very short summaries on the different aspects. Nevertheless, it provides some good suggestions which topics should be covered and how to document them.

Key takeaways:

  • Software architecture documentation should be complementary to the code and describe what the code itself doesn’t. For example, it’s really hard to identify things like architectural principles, operational aspects and how security works from just the code itself.
  • Keep it short and useful
  • What it should contain:
    • Explanation of the software structure
    • The architectural principles and constraints
    • Development and deployment technologies and platforms
    • A justification of how the architecture satisfies the requirements

You can find the slide set here.

BTW: Coding the Architecture contains a lot of useful resources for software architects.

97 Things Every Software Architect Should Know

In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects — including Neal Ford, Michael Nygard, and Bill de h ra — offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience. Among the 97 principles in this book, you’ll find useful advice such as:

  • Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
  • Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
  • Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
  • Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
  • For the End User, the Interface Is the System (Vinayak Hegde)
  • It’s Never Too Early to Think About Performance (Rebecca Parsons)

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project.

You can find the 97 things for free here.

Links for Software Architects

Over the time, I have collected some links to websites and articles with topics interesting for Software Architects. Since they might be of interest for others, too, I am providing them here for you. If you also have some links which you think are interesting for other Software Architects, please let me know.

Links for Software Architects weiterlesen

Professional Software Development

What defines a professional developer? The initiative „Clean Code Developer“ (german only, english version using Google Translate) tries to facilitate a common understanding of this question. It has started to collect principles, rules and best practices for better software.

They see as basic principle for becoming a professional developer to be self-conscious about your work and always try to improve yourself as well as to adhere to some common best practices and working principles. Trying to lead developers to more professionalism, they have also collected a lot of concrete recommendations for the day to day work. To make it easier to follow these practices and rules, all recommendations are grouped by a so-called grade system. So you can start with the easy ones and get to the maybe not so easy to follow rules later.

Even if you don’t agree to all suggested practices and principles, the side is definitely worth a read since you will find a lot of good practices concentrated on one location. Additionally, they also maintain a link list for useful tools and frameworks.

You can find the Clean Code Developer initiative here.

The most important thing about optimization is analysis

You can’t fix a problem by simply trying different solutions to see if they work. In order to fix a problem, you have to understand the problem first.

So, please, if you’re a developer, don’t assume saving a couple of CPU cycles here or there will solve the problem. And if you’re a manager, don’t assume some new hardware will solve the problem. Do some analysis first. Finding out if disk I/O, memory, CPU cycles or single threading is the problem is really not that hard if you spend a little time thinking about it and benchmarking various things. And in the end, you’ll have a much better overview of the situation and the problem, and you’ll be able to come up with specific solutions which will actually work.

And that’s how you save money.

via | Log.

Writing better commit messages

If you and your team are in the habit of writing good commit messages, it can save everyone a tremendous amount of time and effort. Other developers can very quickly see what you’ve done. It’ll also save tons of time tracking down commits from the past when you need to find them. A good commit message serves exactly two purposes: it gives other developers an explanation of the commit, and it gives some documentation for future searching.

Read one for some good rules on writing commit messages.

via » Blog Archive » Writing better commit messages.

Don’t Live with Broken Windows

As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can’t fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn’t trust it, shouldn’t go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. „Well, that’s broken. Oh I just broke that. Oh well.“

via Don’t Live with Broken Windows.