By  (originally published in French on the Xebia blog)

Delivering a stable Android application in production is not easy. At Devoxx, Lordanis Giannakakis explained the techniques implemented at Shazam to speed and reliability of the cycle of releases. This is no mean feat when you consider that Shazam has no less than 100 million active users, and 500 million in total since the inception of the service. Moreover, when you’re dealing with a project of this scale, the need to automate and put the primary focus on adding new features is of the highest importance.

Why Automate?

One thing is clear: the cost of manual testing goes up as the number of builds increases. Whilst we can see that test automation incurs some initial extra costs, these are rapidly compensated down the line. Automation also allows you to run these tests more regularly, and get feedback earlier on in the development phase.

Screen Shot 2014-12-01 at 12.42.25

Source:  http://testdroid.com/testdroid/5851

An approach for BDD

Behaviour Driven Development is a methodology which was designed by Dan North in 2003. The guiding principle behind it is to promote communication between the different actors involved in a software project. This is made possible by the use of a common language combined with a domain-specific language to describe the features of a product.

Screen Shot 2014-12-01 at 12.43.15
From the point of view of the developer, it helps to focus on why the code should be created, rather than the technical details.

In our case, it all starts with the writing of an acceptance test that fails to describe the functionality to be added. A TDD cycle engages in order to implement the desired behavior. Once this cycle is complete, the acceptance test must succeed.

Hello Gwen!

At Shazam, acceptance tests are written using the libraries Robotium and Espresso (ongoing migration). However, these are technical libraries that do not support writing BDD oriented tests. This is why Shazam teams developed Gwen! Gwen is a library that allows you to easily transform an acceptance test “technique” to a syntax Given / When / Then.

With the given Gwen Espresso test:

public  void  testUserLogin () {
    OnView (withText (R.string.username)) perform (TypeText (. "John" ));

    OnView (withText (R.string.password)) perform (TypeText (. "Doe" ));

    OnView (withText (R.string.login_button)) perform (click ().);

    OnView (withId (R.id.view_in_new_screen)) check (matches (isDisplayed ()).);
}dropoff Window

 becomes:

public void testUserLogin() {
    given(user).enterLoginDetails("John", "Doe");

    when(user).login();

    then(user).seeNewScreen();
}

Concrete examples of tests are available in the repository: https://github.com/savvasdalkitsis/bdd-with-gwen

MVP for Testability

To simplify writing unit tests, Shazam teams have adopted the pattern MVP for their application. One difference between MVC and MVP is the fact that, with MVP,  the presenter will be responsible for adapting the data for the model and the view. Thus, all the business logic contained in the presenter will be easier to test and will have less adherence to the Android SDK. With this approach, Shazam are able to limit the use of Robolectric. Indeed, they do not need to test any activities or fragments because the real value of an application lies in the presenters. They do not test the entertainment as too complicated and it has no real interest. They prefer to do it manually.

Screen Shot 2014-12-01 at 12.47.54

To make testing the different parts of their application easier, they also employ injection of dependencies. Surprisingly, Shazam don’t use Dagger, but instead prefer to use their own implementation.

Continuous Integration

Shazam employ Jenkins to regularly push out basic tests. With regards to acceptance tests, the team runs Spoon every night. However, the execution time for these tests continues to grow. Indeed, Spoon executes the set of acceptance tests on each of the connected devices. To work around this problem, they decided to develop Fork, a Spoon library developed to create pools of devices. Thus, tests can be spread over all the devices in a pool to speed up the execution time. This allows the developer not only to have a more rapid feedback, but above all, to run acceptance tests before pushing out their code. With Fork, developers can have a running time close to those unit tests.

It’s no secret that acceptance tests have an annoying tendency to be flaky (or just fail randomly). To work around this problem, Shazam monitor and archive the execution status of their tests. If a test fails regularly or on a set of devices, this indicates that the test needs to be corrected.

Screen Shot 2014-12-01 at 12.48.55

Finally, Shazam use a client adb remote ( https://github.com/sleekweasel/CgiAdbRemote ) to connect and interact with remote testing devices.

Conclusion

Although testing is easier than you think, it still requires a lot of practice. While Android-testing tools are not perfect, things are improving and are moving in the right direction. With all these techniques, Shazam teams have managed to increase the coverage of their application while reducing the number of violations. They manage to deliver faster and are more confident about the stability of their application.

How to Build Rock-Solid Apps and Keep 100M + Users Happy

| Modern Web| 1,009 views | 0 Comments
About The Author
-

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>