Publié par
Il y a 3 années · 5 minutes · Android, Events, Mobile

Devoxx – How to build rock-solid apps and keep 100M+ users happy

image2014-11-23-23261.png

Délivrer une application Android stable en production n’est pas chose aisée. C’est dans ce sens que Iordanis Giannakakis nous explique les techniques mises en place au sein de Shazam pour accélérer et fiabiliser le cycle des releases. Pour rappel, Shazam ce n’est pas moins de 100 millions d’utilisateurs actifs et 500 millions depuis la création du service. Lorsqu’un projet prend une telle importance le besoin d’automatiser se fait vite ressentir afin de pouvoir se focaliser principalement sur l’ajout de nouvelles fonctionnalités.

 

Pourquoi automatiser ?

Le constat est clair, le coût des tests manuels ne cesse d’augmenter à mesure que le nombre de builds augmente. On peut aussi constater que l’automatisation des tests a un certain coup d’entrée qui est vite compensé par la suite. L’automatisation permet aussi d’exécuter ces tests plus régulièrement et ainsi avoir un feedback au plus tôt lors de la phase de développement.
image2014-11-24-0031.png

Une approche orientée BDD

Le Behaviour Driven Development est une méthodologie imaginée par Dan North en 2003. Il a pour but de favoriser la communication entre les différents acteurs participant à un projet logiciel. Cela est rendu possible par l’utilisation d’un language commun combiné à un Domain Specific Language pour décrire les fonctionnalités d’un produit. Du point de vue du développeur cela permet de se concentrer sur les raisons pour lesquelles le code doit être créé, plutôt que les détails techniques.

 

Dans notre cas, tout commence par l’écriture d’un test d’acceptance qui échoue pour décrire la fonctionnalité à ajouter. Un cycle TDD s’enclenche afin d’implémenter le comportement souhaité. Une fois ce cycle terminé le test d’acceptance doit réussir.
image2014-11-23-23032.png

Bonjour Gwen !

Pour Shazam les tests d’acceptance sont écrits à l’aide des bibliothèques Robotium et Espresso (migration en cours). Cependant, ce sont des bibliothèques techniques qui ne favorisent pas l’écriture de tests orientés BDD. C’est pourquoi les équipes de Shazam ont développé Gwen ! Gwen est une bibliothèque qui permet de transformer simplement un test d’acceptance “technique” vers une syntaxe Given/When/Then.
Grâce à Gwen le test Espresso suivant :
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()));
}
devient :
public void testUserLogin() {
    given(user).enterLoginDetails("John", "Doe");

    when(user).login();

    then(user).seeNewScreen();
}
Des exemples concrets de tests sont disponibles sur le repository : https://github.com/savvasdalkitsis/bdd-with-gwen

MVP pour la testabilité

Pour simplifier l’écriture des tests unitaires, les équipes de Shazam ont adopté le pattern MVP pour leur application. Une des différences entre MVC et MVP réside dans le fait que le presenter aura la responsabilité d’adapter les données entre le modèle et la vue. Ainsi, toute la logique métier sera contenue dans le presenter qui sera plus facile à tester et aura moins d’adhérence au sdk Android. Grâce à cette approche, ils parviennent à limiter l’utilisation de Robolectric. En effet, ils n’ont plus besoin de tester les activités, ni les fragments car la vraie valeur ajoutée d’une application réside dans les presenters. Ils ne testent pas non plus les animations car trop compliquées et cela n’a pas de réel intérêt. Ils préfèrent le faire manuellement.image2014-11-23-23052.png
Pour tester plus facilement les différentes parties de leur application, ils font aussi appel à de l’injection de dépendances. Chose surprenante, ils n’utilisent pas Dagger et préfèrent utiliser leur propre implémentation.

Intégration continue

Pour faire tourner régulièrement cette base de tests ils font appel à Jenkins. En ce qui concerne les tests d’acceptance ils utilisent Spoon qui s’exécute toutes les nuits. Cependant, le temps d’exécution de ces tests ne cesse de s’allonger. En effet, Spoon exécute l’ensemble des tests d’acceptance sur chacun des devices connectés. Pour contourner ce problème ils ont décidé de développer Fork, une bibliothèque inspirée de Spoon permettant de créer des pools de devices. Ainsi, les tests peuvent se répartir sur l’ensemble des devices d’un pool pour en accélérer le temps d’exécution. Cela permet au développeur d’avoir un feedback plus rapide mais surtout de pouvoir exécuter tous les tests d’acceptance avant de pusher leur code. Grâce à Fork, ils parviennent à avoir des temps d’exécution proches de ceux des tests unitaires.
Ce n’est pas un secret, les tests d’acceptance ont la fâcheuse tendance d’être flaky (échouent aléatoirement). Pour contourner ce problème, ils monitorent et archivent les status d’exécution de leurs tests. Si un test échoue régulièrement ou sur un ensemble de devices, cela indique que le test a besoin d’être corrigé.
image2014-11-23-232219.png
Pour finir ils utilisent un client adb remote (https://github.com/sleekweasel/CgiAdbRemote) pour se connecter aux devices de test à distance et ainsi interagir avec.

Conclusion

Finalement le testing est plus simple qu’on ne le pense, cependant cela requiert malgré tout beaucoup de pratique. Même si les outils de testing sur Android ne sont pas parfaits, les choses s’améliorent et vont dans le bon sens. Grâce à toutes ces techniques, les équipes de Shazam ont réussi à augmenter le taux de couverture de leur application tout en diminuant le nombre de violations. Ils parviennent à livrer plus rapidement et sont plus confiants quant à la stabilité de leur application.

Thomas Guerin
Consultant Java

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *