Android & BDD tests. Part 1 – Challenge definition

How’re you doing everyone? I hope you had happy funny holidays and rested enough!

I posted many articles with lots of text during the last months and I thought – why wouldn’t I start this year with something different? Something fresh and new that I’ve never posted before. The idea that came into my mind was challenging and interesting at the same time – to create a series of articles where I will learn something new and describe it in “real-time” (if such word is applicable for a blog). That means that I won’t do preparation of a project/code for all posts in advance but do it one by one, explaining the process, deciding solutions and also making mistakes (yes, yes, nobody’s perfect). I have no idea what kind of result will be achieved in the last article of this series as well as how many posts will be added in total. This is an experiment 🙂

So, the challenge for the whole series is…

…to implement behavior-driven tests for an Android application. Sounds easy but there are several tight places in the scope of such project:

The first question is how a behavior-driven development (BDD) framework can be run from the Android test project? As you know, Android instrumentation tests are run on a device as a separate test application, so I need to figure out how to make them friends.

The second question is which testing framework should be used for interacting with an application under test? There are several industry leaders like Appium, UIAutomator, Espresso, Robotium but which one is the best?

The third question is about the architecture (it’s always about the architecture, right?). Choosing correct approaches like a test layers structure, design patterns and so on affects framework maintainability and extendability. This is extremely important to pay attention to from the very beginning of a project since almost every new line of code added to a project without a well-thought-out architecture will lead to chaos and huge human resources spent for extending it.

I’m pretty sure that many of you have (or had) the same questions. Let’s move on and try to find answers…

Application under test

As an application under test, I chose Timber. This is a very nice Android music player with a minimalistic material design but enough features for creating BDD scenarios. Another very important aspect is that Timber is an open-source application and its code is available on GitHub. So, I will have access to the application activity through the AndroidInstrumentation framework (will see in the later posts).


I wish I could take Spotify application for Android for this experiment, to be honest. That could be a very good example of a complex AUT, with lots of UI elements and user scenarios. However, since their source code isn’t public and I don’t have it, Timber is a good replacement for demo purposes. Now, let’s explore the application a little bit and pick out some main user scenarios I could cover first of all…


When the app is opened, there are 3 main tabs displayed: songs, albums and artists. Apparently, each tab contains just different lists of content for user convenience to navigate through a music collection. There is also the main menu with several items like Library (opened by default), Playlists, Folders, Playing Queue, Settings, etc. Except that, there is also search and context menu icons on top of each page (activity). Each song has its own context menu where a user can select applicable actions with it. When a user taps on a song it can be played either in the full-screen player or via the mini-player at the bottom.

Let’s highlight a couple of user scenarios that would be nice to have them covered by autotests:

  1. A user opens the app, searches for a specific song and plays it.
  2. A user adds a certain song to the playing queue and that song is played next.

Very common cases, aren’t they? Let’s start with them then. In the next post, I’ll choose a BDD framework and inject it into the Timber Android project. I’ll also describe the above-mentioned scenarios using the BDD language and make some investigation of the future architecture of the test framework. Stay tuned!

Like this post?

Subscribe to updates from my blog, if you don't want to miss more interesting future posts and materials

Please check your email and confirm subscription

Pin It on Pinterest

Share This