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.
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.
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 :
[java]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()));
}[/java]
devient :
[java]public void testUserLogin() {
given(user).enterLoginDetails("John", "Doe");
when(user).login();
then(user).seeNewScreen();
}[/java]
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.
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é.
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.
Commentaire