Suite aux évènements suivants auxquels j’ai assisté, je tenais à vous faire partager mon ressenti, à savoir :
– De compiletout.bat a l’Usine Logicielle pour Java
– Implémenter la qualité sur un projet Java (REX XWiki)
– 5 ans et 500 releases en 50 minutes ! (REX Sonar)
– Les tests pourquoi et comment ?

Ces conférences auront rappelé, si ce n’était pas encore une évidence, que la qualité des développements passent par des tests automatisés et la mise en place d’usines logicielles en évitant d’être dogmatique sur les pratiques et les méthodes.

Pour mon planning et les pointeurs vers les technologies que j’ai retenu, vous pouvez vous référez ici.

De compiletout.bat a l’Usine Logicielle pour Java

La conférence de Guillaume Rams est exhaustive et synthétique et permet d’avoir un rapide tour d’horizon des outils :
– de gestion de sources
– d’automatisation du build
– de gestion des dépendances
– de référentiel d’artifact
– d’intégration continue
– de déploiement continue
– de développement intégré (IDE)
– de qualimétrie
– de cloud computing (plateforme as a service)

Guillaume rappel et met en avant que :
– le déploiement doit être automatisable car il nécessite un grand nombre de paramétrages en fonction des environnements de test, d’intégration, de recette et de production (données, conf serveurs web, conf bdd, …).
– certains outils sont très encadrants donc dogmatiques, tel Maven, si vous devez les tordre alors ne les utilisez pas
– les outils de qualimétrie ne remplacent pas le pair-programming et la transmission de savoir dans l’équipe. Ils sont là pour alerter et challenger.
– vérifier que les outils fonctionnent en déconnecté pour ne pas perdre en productivité et facilité l’utilisation nomade (ex: gestion de source décentralisée avec Git)
– UML ne peut pas tout décrire, mais le garder pour définir des diagrammes de séquences complexes

Très bonne idée de Guillaume d’avoir structuré sous la forme : pratiques usuelles, challengers, perte de vitesse.  J’y ai retrouvé mes outils du quotidien, à savoir : Eclipse, Git, Gradle bien loin de nos premiers .bat :). Et vous ? N’hésitez pas, c’est ici pour les slides.

XWiki et Sonar, de très bons retours d’expériences

Les retours issus des projets XWiki et Sonar sont très instructifs. Les speakers précisent bien que leur expérience est valable dans leur contexte et si certaines de leurs solutions peuvent s’appliquer à votre contexte tant mieux.

En effet, dans un projet de nombreux facteurs interviennent (ressources disponibles, politique de l’entreprise, maturité des mentalités, compétences, et bien d’autres encore …) qui peuvent empêcher la mise en oeuvre de ces solutions.

Si vous ne connaissez pas et si vous voulez connaître d’autres manières d’appliquer Scrum dans vos projets, vous pouvez lire l’excellent « Scrum depuis les tranchées » d’Henrik Kniberg.

REX XWiki : Implémenter la qualité sur un projet Java

Implémenter de la qualité sur un projet de développement fait appel à de nombreuses techniques (méthodologies, design du code,  design des packages, design des modules, …), c’est pourquoi Vincent Massol s’est focusé sur 5 pratiques, à savoir :
– Test Coverage
– Track Bugs
– Stable Automated functionnal Test
– Ensure API Stability
– Prevent Jar Hell

Pour chacune des pratiques, il rappelle les problématiques associées, et dans le contexte de XWiki quelles solutions ont été mises en oeuvre, principalement en s’appuyant sur des plugins maven.

Test Coverage

– Problème : sans stratégie de code coverage possibilité que les bugs augmentent
– Stratégie : jacoco-maven-plugin avec une configuration basée sur un ratio par module qui bloque le build

Track Bugs

– Problème : nombre de bugs créés est supérieur au nombre de bugs clôturés
– Stratégie : 1 jour par semaine consacré à réduire le nombre de bugs (requiert un leader pour challenger l’équipe :) avec un tableau de suivi.

Stable Automated functionnal Test

– Problème : beaucoup de faux positifs liés aux environnements d’exécution, des données corrompues, ressources non disponibles, …
– Stratégie : ajouter sur Jenkins les plugins groovy postbuild, Email-ext (PreSend Script),Scriptler pour gérer ce comportement sur tout les jobs.

Ensure API Stability

– Problème : assurer la bonne utilisation des api publiques et/ou privées au cours de leurs évolutions
– Stratégie : @Deprecated, plugin maven clirr, package internal, module legacy, création annotation custom @Unstable (garde fou pour les jeunes api), Java8 et Virtual Extension/Defender method.

Prevent Jar Hell

– Problème : Runtime Class Not Found / Method Not Found (ex: slf4j-api 1.4.0 et logback-0.9.9)
– Stratégie : maven-duplicate-finder-plugin (No duplicate Class au Runtime), maven-enforcer-plugin

REX Sonar : 5 ans et 500 releases en 50 minutes !

Pour ce retour d’expérience, très bien mené, ce que j’en ai retenu de nouveau.

La maintenance des Tests d’Intégration (TI) devient un véritable investissement. Chez Sonar, ils ont développés un framework pour aider à bâtir les TIs.

Il faut se protéger des TIs faux positifs en écrivant des tests qui prennent en compte l’absence des ressources (timeout, messages explicites d’erreurs, …)

La gestion d’équipe agile est difficile avec le télétravail (national ou international) et nécessite une rigueur dans les horaires de chacun pour être là quand l’équipe est au complet. Le développeur qui travaille jusqu’à 3h du matin et n’est pas là pour la Daily Scrum c’est pénalisant.

Les tests: pourquoi et comment ?

Les 3 speakers étaient excellents d’autant plus qu’ils travaillent chacun dans des domaines différents, à savoir : définition des besoins en tant qu’assistant PO, Développeur Back Office Java, Développeur Front Office JS.

Leur expérience est basée sur leur mission actuelle chez Mappy qui a fait naître des bonnes pratiques de test dans chacun de ses domaines. De plus, ils indiquent les outils qu’ils ont utilisés, de quoi enrichir notre boîte à outils.

Ils ont conduit leurs conférences selon 3 axes : Pourquoi tester ? Comment ? Notre expérience.

Pourquoi tester ? et Comment ?

Pourquoi tester ?
– Nous pouvons obtenir la spécification du produit directement dans le code grâce au test.
– Rend plus lisible l’objectif du code et aide au Definition of Done (DoD) et le Reste à Faire (RAF)
– Permet de détecter les problèmes au plus tôt pour les débugger

Comment ?
Il faut définir une stratégie en amont pour que l’équipe soit alignée :
– frameworks à utiliser et manière d’écrire les tests
– mise en place de Code Review
– mise en place de Coding Dojo pour résoudre des problèmes simples et ainsi respecter les principes et obtenir une homogénéité des développements
– essayer de faire cela en mode jeu, par exemple avec des plugins sous eclipse (PairHero, TDGotchi)
– mettre un binôme responsable de la maintenance du build

Notre Expérience

Aider et accompagner les équipes à se former sur TDD. Il ne faut pas être dogmatique sur les tests et diffuser la pratique du TDD par le lead, c’est à dire l’avoir pratiqué soit même et montrer les bienfaits par la pratique pour que autres membres de l’équipe adhèrent ou non mais sur des bases concrètes.

Un petit tableau récapitulatif des axes à suivre.
—

Savoir prioriser	Partager	Lisibilité	Facilité d’écriture
Choix de technos reconnues	Rapidité d’exécution	Paralléliser
Analyser	Améliorer	Refactorer	Comprendre les bugs

—
Savoir prioriser
– vérifier les contrats des APIs en priorité avec des tests sur les services
– utiliser la priorisation verticale (pyramide de Mike Cohn)
– utiliser la priorisation horizontale (chemin critique)
– utiliser The MoSCoW principle sur les fonctionnalités
– savoir créer des tests boîtes noires de plus haut niveau sans faire de tests sur les éléments constitutifs

Partager
– tests écris par l’équipe et le PO via Fitnesse
– le produit est accessible à tout le monde
– les tests sont accessibles à tout le monde

Lisibilité
– utilisation du Given/When/Then (les tests doivent êtres moins compliqués que le code)
– utilisation des underscore (_) plutôt que CamelCase (intention du test dans le nom de méthode devrait être suffisant)
– soyez explicite en détaillant avec des variables
– asserThat(xml).isWellFormed() (factoriser les assertions)

Facilité d’écriture
– passer très peu de temps à écrire les tests en s’appuyant sur des frameworks de test (bien lire les fonctionnalités)
– utiliser des Fixtures pour alimenter les datas
– factorisation des données avec des Factory
– factoriser le code avec @Parameters

Choix de technos reconnues et partagées par l’équipe
– CasperJS (valider interface web) au lieu de code java Selenium
– PhantomJS (création de screenshots des pages webs)
– Webkit ou V8

Rapidité d’exécution
– @test(timeout=1000)
– Assume.assumeTrue(canWriteInThatEnvironnement())  (vérification de Ressources avec JUnit)
– @BeforeClass et @AfterClass (rendre très petite l’empreinte mémoire et CPU)
– Fixture vs Factory
– éviter les injections de dépendances au profit des Mock/Stub
– 1 besoin par test
– tools Infinitest pour prioriser les tests et avoir un feedback au plus tôt.
– utiliser AssertThat au lieu de AsserTrue et utiliser la chaine texte si jamais KO dans les tests

Paralléliser
– utiliser GNU Parallel
– paramétrer votre usine logicielle pour qu’elle soit scalable (ici un exemple avec Jenkins)

Analyser
– analyser les traces des tests
– les traces doivent être utilisables par d’autres services (ex: cellule qualité logicielle)

Améliorer
– détection en continue des problèmes dans les données
– mise en place de Watchdog pour vérifier que les données sont correctes et non corrompues
– passer les tests sur les environnements de prod
– ne pas couvrir le code à 100% mais plutôt s’orienter sur une couverture fonctionnelle du code (le PO est ainsi satisfait car le produit réponds aux attentes)
– un bug = un nouveau test ou = une correction de test ou = une modification de test existant si c’est un nouveau besoin produit
– détection des comportements utilisateurs en analysant les logs

Refactorer
– type 1, pas de changement du périmètre fonctionnel seulement en terme de performance et de design
– type 2, changement du périmètre  fonctionnel nécessite de changer le test
– attention à ne pas faire les deux en même temps

Comprendre les bug
Par exemple entre 2 releases si des problèmes de performances apparaissent et vous souhaitez savoir quel commit a introduit la défaillance ? Vous pouvez utiliser git-bisect.

Conclusion

Pour que votre investissement dans vos tests ne représentent que 50% de charge en plus : Soignez vos tests en vous appuyant sur des outils reconnus par l’équipe et suivez les bonnes pratiques !