Applications avec lesquelles vous pouvez vivre

Vous passez plus de temps à modifier, étendre, améliorer et (occasionnellement) corriger des applications qu’à les créer. Une suite de tests fiable confirme que vous disposez d’une application qui prendra en charge ces activités.

Il existe au moins trois critères pour mesurer la qualité d’un logiciel :

• Faibles coûts d’entretien : Notre organisation peut-elle vivre avec ces applications ?
• Aptitude à l’objectif: Les applications que nous livrons font-elles leur travail ?
• Processus de livraison fiable: Pouvons-nous livrer ces applications quand nous avons dit que nous le ferions ?

Il y a lieu d’affirmer que les « faibles coûts de maintenance » sont le seul critère qui compte : les développeurs de logiciels dépensent 35% de leur temps sur la gestion du code existant– et cela n’inclut pas « l’amélioration du code existant ». À titre de comparaison, les développeurs consacrent moins de 12 % de leur temps au développement « greenfield ».

De toute évidence, l’amélioration de votre capacité à créer des applications qui peuvent être facilement étendues et modifiées aura un gain bien plus élevé que l’amélioration de votre capacité à créer de nouvelles applications.

Maintien de la compatibilité

Une partie du problème est que la modification d’applications existantes présente au moins un problème que le codage « greenfield » n’a pas : maintenir la « compatibilité descendante ». Modifier le code existant, c’est comme travailler sur le moteur d’une voiture tout en s’assurant que le conducteur peut toujours diriger et arrêter la voiture… et le faire pendant que la voiture roule sur l’autoroute avec des passagers à l’intérieur, entourés d’autres voitures, toutes avec des passagers à l’intérieur.

Les tests ont ici un rôle majeur à jouer. Si vous avez des tests de régression pour le code que vous modifiez, alors, après avoir apporté une modification, vous pouvez prouver que la partie de votre application qui est censée ne pas être affectée fonctionne toujours « comme avant ». Comme vous n’avez jamais assez de temps pour tout tester de régression, les tests automatisés sont votre meilleur choix ici.

D’ailleurs, si votre code existant n’a pas de tests automatisés, ce n’est pas un problème d’en ajouter : vous avez stratégies multiples pour faire ça.

Tests automatisés et applications maintenables

Si vous essayez d’évaluer à quel point il sera difficile/coûteux de modifier une application, vous pouvez rechercher plusieurs principales caractéristiques. Ces fonctionnalités sont obtenues en écrivant des applications qui sont :

Ce qui est également vrai du code qui prend en charge les tests automatisés. S’il est difficile/coûteux/long de créer des tests, c’est un signe que votre application va être difficile/coûteuse/longue à maintenir.

Par exemple, le principe de responsabilité unique (le « S » dans SOLID) dit qu’un objet doit faire « bien une chose ». Le principe de ségrégation d’interface (le « I » dans SOLID) garantit que la fonctionnalité est segmentée par client. Le principe d’inversion des dépendances garantit que l’interface est conçue en fonction des besoins du client (le « D » de SOLID).

Les applications construites selon ces trois principes nécessitent moins de tests plus simples pour prouver qu’elles fonctionnent : vous n’avez qu’à prouver que la « responsabilité unique » de l’objet est remplie, vous n’avez qu’à créer des tests pour un seul client à la fois, et vos tests n’ont pas pour traiter les membres d’interface superflus. Les tests sont plus petits, plus faciles à écrire et plus faciles à comprendre, et peuvent être créés plus rapidement que les tests pour les objets qui ne suivent pas ces principes.

Le principe ouvert/fermé (les objets sont ouverts à l’extension et fermés au changement – le « O » dans SOLID) signifie que vous pouvez créer un test en étant sûr que le test est bon pour l’avenir prévisible de l’objet car l’objet est fermé au changement . Selon le principe Ouvert/Fermé, les modifications d’un objet sont apportées en créant des extensions distinctes de l’objet. Vous pouvez ensuite créer des tests séparés pour ces extensions, en vous assurant que ces tests sont indépendants des tests de l’objet d’origine.

Le principe de substitution de Liskov (le « L » dans SOLID) réaffirme le principe ouvert/fermé pour l’héritage. Pour les objets qui suivent le principe de Liskov, tout test appliqué à un objet de base peut être appliqué à tous les enfants de l’objet de base. Pour tout objet enfant, il vous suffit d’ajouter des tests pour la fonctionnalité que l’objet enfant ajoute à l’objet de base.

La Caractéristiques de composants faiblement couplés – qu’ils peuvent être mis à niveau, modifiés ou remplacés avec un impact minimal sur les autres composants – facilitent également le test unitaire de ces composants et leur combinaison avec d’autres composants pour créer des tests d’intégration.

Examens manquants

Et si vous pensez qu’il y a une partie de votre application qui n’a pas besoin d’être testée, c’est probablement une erreur : tout ce que vous ne testez pas aura au moins un bogue. Probablement plus.

Dans son livre classique sur le développement logiciel, «Le mois de l’homme mythique : essais sur le génie logiciel», Fred Brooks parle du développement du système d’exploitation System 360. Au départ, les équipes n’ont pas mesuré ni testé l’utilisation de la mémoire par les composants individuels du système d’exploitation. Sans surprise, lorsqu’ils ont essayé d’utiliser les composants ensemble, ils ont trouvé plusieurs bogues liés à la mémoire.

Une dernière note sur la valeur des tests : Au cours de la vie d’une application, de nombreuses personnes seront impliquées dans la maintenance d’une application. Essais automatisés sont une documentation sans ambiguïté de ce que tout composant est censé faire : Le composant est censé réussir ce test. Toute partie d’une application qui n’a pas de test associé est une partie de l’application dont le comportement est, essentiellement, inconnu des personnes qui doivent maintenir l’application.

Il y a donc un « méta-test » ici : vous pouvez déterminer si vous avez créé une « application maintenable » en créant une suite de tests automatisés pour celle-ci. Si vous ne pouvez pas, vous avez probablement une application qui va être difficile à maintenir et à étendre. De plus, dans un sens très réel, vous avez un système qui n’est pas documenté, peu importe la quantité de papier que vous avez à ce sujet. Enfin, lorsque vous venez modifier l’application, vous aurez une capacité très limitée à faire des tests de régression qui détermineront l’impact de vos modifications.

En d’autres termes : sans suite de tests, votre application ne sera pas bien comprise, sa maintenance sera coûteuse et vous ne saurez pas à quel point vous rencontrez des problèmes lorsque vous irez la modifier. Pas un bon endroit pour être.

Ensuite, vous voudrez peut-être en savoir plus sur d’autres critères de mesure de la qualité des logiciels : livraison fiable et aptitude à l’emploi.