JCrete 2013 – Maintaining that test codebase

Lors de la troisième journée de JCrete 2013, Dmitry Jemerov, project lead chez Jetbrains a lancé une grande discussion sur la maintenance des tests applicatifs.

Les sessions ont toutes été enregistrées (audio seulement) et seront publiées sur le site WikiEducator à l’adresse : http://wikieducator.org/index.php?title=JCrete2013:Blog

Dans la grande série des discussions ouvertes, nous voici en pleine réflexion sur la maintenance des tests d’une application. Dmitry nous explique que la plateforme IntelliJ a été créée en 2001, il s’agissait alors d’un simple éditeur Java, et qu’elle comporte aujourd’hui plus de 20.000 tests (unitaires, intégration et acceptance).

Problème : aujourd’hui, les tests prennent plus de 4h à s’exécuter, et leur séparation par packages n’a pas permis de résoudre le problème. Ils n’ont pas assez d’agents d’exécution sur leur plateforme de CI pour jouer tous les tests à chaque commit.

Nous avons eu des points de vue variés sur Cucumber. Parfois jugés trop complexes et remplacés par JUnit, difficiles à utiliser pour des test sur mobile, utilisés à bon essient avec les équipes QA qui écrivent leurs scénarios eux-même, …

Alex Snaps, développeur sénior chez Terracotta nous fait part d’autres problèmes, notamment liés au turn-over. Lorsqu’un nouveau développeur arrive, il lit d’abord la documemntation, qui est probablement mensongère, puis exécute les suites de test (45 min, black-box et white-box) et s’en sert comme point d’entrée dans le système.

Les tests doivent donc être très lisibles et expressifs, parce qu’ils deviennent une partie de la documentation. Propos confirmés par un développeur de chez Neo4J, qui explique que des fragments de code sont extraits des tests pour être inclus dans la documentation (asciidoc).

Pour diminuer le problème du turn-over, en complément de tests lisibles, l’accent est mis sur la capacité des developpeurs à se former ensemble, par le biais du pair-programming ou des code-reviews. Cependant le pair-programming implique la colocalisation des équipes, ou au moins beaucoup d’infrastructure (team viewer, skype, …) et d’engagement. Un plugin pour faciliter le remote pair-programming a été soumis à JetBrains mais n’a pas encore été implémenté (http://youtrack.jetbrains.com/issue/IDEABKL-708).

Chez JetBrains, il n’y a pas vraiment de budget dédié au refactoring. Les refactorings sont décidés au cas par cas, car chaque changement implique un coût et un risque, et il faut s’assurer que ce changement impliquera des bénéfices. Ce point est une variante du "If it works, don’t fix it" et peut être formulé en "If it works and change is only dogmatic, don’t fix it".

Un refactoring, même automatique, peut introduire des régressions. Il implique une revue de code (ou du pair-programming) et nous devons donc nous assurer que le changement en vaut la peine. Ce point est résumé par Martin Thompson par "Change the code only when there is a good reason to do it".

Ce point a sucité de très vives réactions. Par exemple, la règle du boyscout "Leave the campground cleaner than you found" implique de toujours améliorer le code. Mais doit-on pour autant améliorer le code qui n’est pas lié à la fonctionnalité en cours de développement ? Est-ce que cette règle dit de nettoyer le camp et toute la route qui y mène ?

Parfois, le refactoring donc peut juste aider à construire une représentation mentale du projet en cours de maintenance, sans être envoyé sur le repository car il n’est pas lié à une fonctionnalité en cours de développement.

Cette session était très enrichissante car elle a permis de confronter des points de vue très hétérogènes, dont les pratiques de Software Craftmanship, des contraintes de Time-To-Market et et le pragmatisme des participants.