Développer pour iPhone ne vous prive pas de faire de la Qualité

Dans mon expérience, j’ai été amené à travailler sur de nombreux projets iOS de toutes tailles, parfois comme développeur, parfois comme auditeur. Je dois dire que s’il y a une constante entre tous ces projets, c’est bien l’absence relative de tests unitaires ou de système d’intégration continue.

On sait bien qu’Xcode propose à la création d’un projet de rajouter une cible “Tests”. Je vois souvent ce dossier dans les projets qu’on m’envoie. Vide, mais présent, comme si on le laissait là pour peut-être un jour rajouter des tests unitaires, mais pas maintenant.

Curieux sur ce sujet, je me suis renseigné autour de moi et il s’avère que les pratiques habituelles de Qualité ne sont pas monnaie courante dans le développement iOS.

Je me demande pourquoi. Est-ce qu’on est immunisé contre les régressions en développant pour iOS ? Je ne pense pas, et on n’a aucune excuse pour ne pas faire ce que font les autres.

Un problème de culture

Il y a 3 ans de cela j’ai lu un article intitulé “It’s not about the unit tests“, il m’est resté à l’esprit. Je vous invite à le lire, il raconte le point de vue d’un développeur rompu aux pratiques de Qualité qui rejoint une équipe de développement iOS qui ne pratique ni tests unitaires, ni intégration continue, rien.

L’auteur “excuse” ces pratiques par le fait que les applications mobiles sont souvent très orientées vue et cinématique, et ces éléments sont assez difficiles à tester ; ou que les fonctionnalités sont limitées et donc facile à cadrer. Il explique aussi que d’une manière générale les développeurs iOS tendent à être plus soigneux vis-à-vis de leur produit, et ça peut se comprendre.

Ces explications se tiennent et j’en vois aussi d’autres.

Quand on travaille sur une application iPhone on aime passer très vite à une application “qui marche” et souvent un prototype bricolé va évoluer pour devenir une application. On avance très vite vers quelque chose de tangible et les tests unitaires peuvent être vus comme un frein néfaste.

Quand le SDK iPhone est sorti en 2008, nul ne savait si l’App Store serait une mode éphémère ou le modèle de distribution du logiciel qu’il a fini par devenir. Beaucoup d’applications sont nées à cette période sous forme de projets rapides, sans recherche particulière sur l’architecture ou la maintenabilité.

À cette époque, la demande pour les développeurs Objective-C a explosé et beaucoup d’autodidactes inexpérimentés se sont lancés sur l’opportunité. Je ne jette la pierre à personne, c’est juste que lorsqu’on apprend sur le tard, on a rarement le temps de se préoccuper des bonnes pratiques qui ne permettent pas juste de “faire avancer le boulot”.

Et puis il a bien fallu se rendre compte au bout d’un moment qu’avoir une App sur le Store demande une équipe, du temps, de l’argent, et que ce qui ressemblait d’abord à une activité périphérique devient vite une part importante du CA. Un projet de refonte coûte cher, alors on reprend l’application bricolée du début et on la fait évoluer, avec toutes les casseroles qu’elle traîne.

Et puis je parle mais j’ai ma part de culpabilité : j’ai touché mon lot de projets et même si j’en ai monté quelques uns en Test-Driven Development, c’était plutôt l’exception que la norme.

Les choses ont changé

Le périmètre des applications mobiles a explosé.

Et les capacités d’une app ont grandi. Il n’y a pas si longtemps, une app ne pouvait être active que lorsque l’utilisateur la regardait, aujourd’hui on a des widgets dans le centre de notifications, des extensions qui leur permettent de dialoguer et même une facette sur la Watch. [Certaines][GarageBand] applicationsiPad proposent des fonctionnalités qui rivalisent avec ce qu’on peut faire sur un bon vieux PC, et comble du comble on arrive à trouver des moyens de les faire tenir sur iPhone aussi, maintenant que l’écran grandit !

Certains géants comme Facebook et Google font des armées d’applications pour diviser les fonctionnalités, mais ça ne simplifie pas nécessairement les choses : il faut notamment penser aux interactions entre toutes ces applications et industrialiser leur déploiement davantage pour accompagner l’évolution des API sur lesquelles elles s’appuient.

Comme les projets qui étaient jadis sous la main d’un ou deux développeurs sont maintenant la responsabilité d’équipes entières, des pratiques claires deviennent un besoin encore plus important : intégration continue, normes de codage, relecture du code, documentation…

Les arguments qui pouvaient tenir en 2012 font pâle figure en 2015, et toute la bonne volonté du monde ne suffit pas, car l’App Store aussi a changé.

La qualité n’est pas accessoire

Il faut dire qu’on réalise maintenant que le smartphone devient l’outil de choix pour accéder à Internet, normal que chacun réclame sa part du gâteau. L’App Store était vu come un El Dorado, c’est maintenant une arène impitoyable où se démarquer du lot n’est pas évident. Vous parlez discrètement à un ami d’une idée géniale pour une app, une chance sur deux qu’il vous dise qu’elle existe déjà.

Et dans cet environnement saturé d’applications, le public est devenu exigeant. En plus d’une UX aux petits oignons et de fonctionnalités qui déboîtent, vos utilisateurs risquent de changer de crèmerie très vite en vous laissant dans un océan de “1-étoile” si vous ne leur donnez pas deux choses : de l’évolution constante et du 0-bug.

L’évolution, c’est non seulement vous assurer que votre application tourne toujours sur la dernière version de l’OS avant qu’Apple ne la sorte, mais aussi l’alimenter constamment en nouveautés, parce que les mises à jour d’iOS le permettent et aussi parce que vos concurrents vont le faire. Vous êtes en marche forcée et si vous trébuchez sur un bug en prod, vous risquez de vous prendre des flammes.

Les bonnes pratiques de Qualité peuvent permettre à une équipe d’avancer plus sereinement dans l’ajout de fonctionnalités et la correction de bugs, en évitant au maximum les régressions qui sont trop souvent vues comme inévitables. Je ne vais pas m’étaler sur les avantages de ces pratiques, des tonnes d’autres articles le font mieux que moi.

Si on pouvait s’en passer quand l’App Store était un “club”, c’est aujourd’hui un atout de choix si l’on veut satisfaire le public.

Nous avons des outils : vous n’avez aucune excuse

Le SDK iPhone a fait beaucoup de chemin depuis sa sortie en 2008, un an après l’amère “Sweet Solution“.

À l’époque il n’y avait pas grand-chose pour cracher ses tests unitaires, tester son UI et faire de l’intégration continue. Vous pouviez toujours bricoler avec des solutions tierces mais il fallait vraiment le vouloir, et on sait tous que si on veut qu’un développeur fasse ses tests, il faut que ce soit facile.

Vous avez regardé les vidéos de la WWDC 2013 ? (Oui, 2013) Je comprends que les sessions “Testing in Xcode 5” et “Continuous Integration with Xcode 5” ne soient pas celles qui ont attiré votre regard : c’était l’année où iOS 7 est sorti avec son nouveau design.

Oui, XCTest et Xcode Bots datent de 2013.

En plus, avant qu’Apple ne présente XCTest, OCUnit existait déjà et était embarqué dans Xcode. Les sujets des tests et de l’intégration continue sont présentés tous les ans à la WWDC depuis. Bien sûr ils n’ont pas le magnétisme que peuvent avoir les nouvelles API juteuses qui permettent de développer de nouvelles fonctionnalités, mais vous pouvez prendre une heure ou deux pour regarder quelques sessions, c’est très instructif.

Vous avez toutes les solutions en main, vous n’avez même pas à vous prendre la tête.

NSHipster couvre très bien XCTest et présente même une élégante solution pour faire du mocking en Swift sans avoir à intégrer de bibliothèque tierce. En août 2014, Objc.io consacrait son numéro mensuel au test en pas moins de 7 articles. Et si vous voulez en apprendre sur le test d’UI, le mieux à faire est de regarder la vidéo de la WWDC 2015 sur le sujet.

Avec quelques bons réflexes vous pourrez facilement documenter vos API en Swift. Et pour ce qui est des bonnes pratiques de codage, Faux Pas peut être une bonne piste à suivre.

Toutes ces pratiques peuvent s’intégrer progressivement dans vos projets, vous n’avez pas besoin de tout révolutionner du jour au lendemain. Il y a des chances que ce soit un peu compliqué au départ, mais que le travail de votre équipe en soit vraiment facilité.

Documentez votre avancée, parlez des outils que vous utilisez, des choix que vous avez faits, alimentez la communauté !

Avec l’arrivée de Swift nous allons recevoir encore toute une vague de nouveaux développeurs. Nous avons l’opportunité d’améliorer la culture du développement iOS, de prendre des bonnes habitudes et de les transmettre aux autres, pour nos apps, pour nos utilisateurs et pour nos équipes. Ne la laissons pas filer, nous n’avons aucune excuse, maintenant.