Pourquoi la qualité du code semble-t-elle, plus que jamais, critiquée ?Si les spécialistes de n’importe quel autre secteur industriel étudiaient la façon de produire le logiciel et les méthodes de détection et de prévention des erreurs, ils penseraient que nous sommes fous. Là où le bât blesse, c’est que, dans le logiciel, il y a, d’une part, le programmeur qui produit le code et, de l’autre, le testeur qui le vérifie. Et ce sont deux tâches bien distinctes. Dans les autres domaines industriels, on ne peut séparer production et contrôle. Personne ne penserait à placer un composant dans un téléviseur simplement pour vérifier s’il marche. En tout cas, plus maintenant.Alors, si l’on peut tester des composants industriels, pourquoi n’arrive-t-on pas vraiment à vérifier des classes ?La réponse est liée à l’économie. Dans l’industrie, vous pouvez amortir les tests sur la masse des composants produits dans la mesure où, sur une chaîne, tous les composants sont semblables. Dans le logiciel, il faut écrire du code spécialement pour tester chaque classe produite. Et il faut aussi réaliser l’environnement de test nécessaire. Et, pour chaque classe, ce sera différent. Aucun amortissement n’est possible. Il est donc impératif de disposer d’un outil logiciel assez intelligent pour produire automatiquement cet environnement. En regardant bien, les deux aspects pouvant être véritablement automatisés sont les tests unitaires et les standards de codage. C’est cette idée qui est à l’origine de notre société. Les standards de codage commencent à devenir populaires parce qu’ils permettent, à eux seuls, d’éviter de nombreuses erreurs, et aussi parce qu’ils peuvent être appliqués à n’importe quel langage. Les tests unitaires sont également très importants : si vous créez une classe, il faut non seulement en écrire le code, mais aussi, en parallèle, préparer le jeu de tests qui s’y applique. Pour être efficace, ce doit être totalement automatique.Quid des méthodes agiles, comme XP, qui incluent des notions de test unitaire ?Ce sont des démarches très intéressantes. Nous utilisons certaines approches de l’Extreme Programming, mais pas tout. Principalement, il s’agit du prototypage rapide. J’y crois beaucoup. Ainsi qu’au test permanent. Pour Insure++ (outil de vérification automatique à l’exécution ?” NDLR), par exemple, qui est un vieux produit, nous avons dû effectuer autour de cent mille cycles de tests. Nous n’avons pas, chez Parasoft, de département qualité. La responsabilité du fonctionnement du logiciel est celle du programmeur. Personne n’intervient après lui. Pour l’aider, deux outils très importants existent : les systèmes de contrôle du code source (Source Control Systems ?” SCC) et l’assemblage nocturne du code (“nightly builds”). Chaque soir, tous les programmes sont extraits du SCC, et sont assemblés et compilés en parallèle. De même, nous parallélisons les suites de tests. Une autre approche que nous utilisons, et que nous poussons nos clients à adopter, est celle de construire la suite de tests avant de coder la fonction. Ainsi, nous savons exactement ce que nous avons à faire, et nous laissons les tests échouer. Car, une fois que la fonction est correctement réalisée, le test est concluant. Les standards de codage prennent une part importante dans ce processus. Pendant la journée, les développeurs ne peuvent valider leur code que s’il passe la vérification des standards.L’évolution prédite vers les services web induira-t-elle des modifications dans la manière de tester ?Bien sûr, parce qu’il existe une grande partie du code sur laquelle on ne peut agir. Des outils plus complets sont alors nécessaires pour vérifier à la fois le code et les interfaces des services distants. Soaptest, que nous venons de lancer, permet de vérifier non seulement le service web en tant que module de code ?” sur un serveur, par exemple, mais aussi l’aspect client. Si vous réalisez une application qui doit accéder à un service distant ?” une banque, par exemple ?”, il y a peu de chances que vous puissiez tester celui-ci avec votre application. Soaptest vous permet de leurrer votre application quand vous n’avez pas accès au service web distant. C’est un outil de vérification de code, mais il assure également des fonctions de test de charge.Mais si vous n’avez pas accès au code de ce service, comment l’émuler ?Les services peuvent être très complexes et proposer de nombreuses fonctions. Mais le test s’effectue du point de vue de votre application, qui n’en utilisera que quelques-unes. Soaptest peut lire le fichier WSDL (Web Service Description Language ?” NDLR). Dès lors, il créera les commandes avec les arguments, enverra les requêtes et vérifiera les réponses. Nous nous servons de la description WSDL du service pour déterminer comment il doit se comporter afin de l’émuler lors des tests.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
