Obtenez des commentaires immédiats sur les changements de code à l'aide de l'analyse d'impact des tests

Plus vite vous pouvez tester, plus vite vous pouvez libérer. Mais vous n'avez pas à attendre la compilation nocturne / quotidienne pour exécuter votre suite complète de tests unitaires pour la validation de l'impact de vos modifications de code. Au lieu de cela, obtenez des informations immédiates sur les tests impactés par les modifications de votre code et soyez plus confiant lors de l'enregistrement.

Les tests unitaires sont une des meilleures pratiques du secteur depuis des années, et à mesure que les équipes de développement développent leurs suites de tests, elles deviennent de plus en plus grandes. Et à mesure que les tests se développent en tests d'intégration ou au niveau des composants, ils prennent plus de temps à s'exécuter. Avec les nouvelles tendances en matière de tests unitaires, tels que TDD, ces suites de tests vont devenir encore plus volumineuses qu'auparavant, car tout le code dépend de tests, et plus encore.

Avoir une grande base de tests unitaires peut être une excellente base pour les tests, mais cela peut avoir un impact important sur le temps d'exécution des tests, d'autant plus que les tests unitaires se développent en tests d'intégration / de niveau composant. Donc, la clé pour savoir quoi tester est de comprendre l'impact exact de chaque changement de code, quels tests doivent être exécutés et quels nouveaux tests peuvent être nécessaires.

Le calcul de la couverture du code est un aspect de la détermination de ce qui a été testé, mais ce n'est pas suffisant en soi. La vraie magie se produit lorsque la couverture de code est calculée pour chaque test, puis corrélée avec les modifications du code sur une base de construction par construction. L'utilisation de cette approche nous donne analyse d'impact de test - qui est le processus par lequel nous identifions exactement quel test exécuter pour valider les changements de code. En exploitant l'analyse d'impact des tests pour les tests unitaires avec Parasoft Jtest, les équipes de développement logiciel peuvent concentrer leurs efforts de test et vraiment accélérer leur pipeline de développement, via le processus IDE ou CI.

Testez l'analyse d'impact à portée de main

Trouver et corriger les bogues le plus tôt possible est le principal avantage d'avoir une analyse d'impact des tests. Avec les résultats de l'analyse d'impact des tests intégrés directement dans l'EDI, les développeurs peuvent exploiter de manière transparente ses avantages dans leur flux de travail, pour concentrer les efforts de test exactement au bon endroit et s'assurer que les modifications de code sont complètement testées, y compris les impacts indirects sur le code associé.

Bien que trouver et corriger rapidement les bogues soit l'objectif principal, il existe d'autres avantages à avoir les résultats de l'analyse d'impact des tests à portée de main du développeur, notamment:

• Mettre en évidence les tests qui exécutent réellement du code dans les fichiers modifiés, en s'assurant que seuls les tests requis sont exécutés.
• Intégration avec une variété de systèmes de contrôle de source et de construction avec la possibilité d'être personnalisé pour prendre en charge un environnement unique en cas de besoin.
• Identifiez non seulement les dépendances directes entre les tests et le code, mais également les dépendances indirectes, pour vous assurer que l'impact total des modifications est couvert par les tests.
• Configuration initiale facile et possibilité d'identifier et d'exécuter automatiquement les tests concernés sans que l'utilisateur n'ait à faire autre chose que changer le code et afficher les résultats.

Lorsque vous combinez l'analyse d'impact des tests avec le processus CI, les gains de temps sont évidents et vous pouvez concentrer les efforts de l'équipe de développement sur exactement ce qui doit être fait pour garantir la qualité. Les optimisations au moment du développement et de la construction sont essentielles pour atteindre les objectifs agiles lors de la gestion des changements.

Des tests ciblés signifient un meilleur logiciel, livré à temps

Il est préférable et moins coûteux de trouver les bogues plus tôt que de les trouver plus tard dans le cycle de vie du développement logiciel, ce qui peut entraîner d'importants dérapages de calendrier. Les développeurs ne savent souvent pas quels tests exécuter, ils n'exécutent donc aucun test ou en exécutent trop peu. Dans ce cas, ils dépendent de la construction, qui est configurée pour exécuter toute la suite de tests, de sorte que les équipes de développement sont inactives en attendant les commentaires / validation du processus de construction concernant leurs modifications. En tirant plutôt parti de l'analyse d'impact des tests, les équipes de développement peuvent trouver et exécuter les tests appropriés avant même de valider le code dans une version pour valider les modifications.

L'analyse d'impact des tests signifie également que les développeurs peuvent obtenir des commentaires plus rapides sur les modifications de code qui provoquent des échecs de test de leur processus CI. Les responsables du développement souhaitent que leurs équipes exécutent des tests avant l'archivage du code, idéalement, mais ce n'est souvent pas fait. De plus, ils veulent s'assurer que leurs équipes savent dès que possible, une fois le code archivé, si le code a cassé des tests. Par conséquent, il est important que la capacité d'analyse d'impact des tests couvre le processus CI ainsi que le bureau du développeur.

Vue «Tests unitaires impactés» de Parasoft Jtest dans l'EDI

Alors, à quoi cela ressemble-t-il en pratique? Dans l'EDI, au fur et à mesure que le développeur écrit du code, la vue «Tests unitaires impactés» de Jtest fournit une liste (en évolution dynamique) des tests qui doivent être exécutés pour appliquer le code qui est modifié localement. Ensuite, tout ce que le développeur doit faire est simplement de cliquer avec le bouton droit sur le test concerné et de l'exécuter ou simplement d'exécuter tous les tests concernés.

Jtest garde une trace des tests affectés qui ont été exécutés et affiche clairement ceux qui ont réussi et ceux qui ont échoué, ce qui permet au développeur de déterminer facilement quels tests doivent encore être exécutés ou quels tests ont échoué et doivent être traités. Une fois que tous les tests ont été exécutés et réussissent, le développeur a plus confiance dans le changement de code et peut valider son code en toute sécurité et passer à la tâche de développement suivante.

Le flux de travail code-test-feedback-remediate est spécialement conçu pour augmenter la productivité sur le bureau du développeur, permettant aux utilisateurs d'identifier et d'exécuter facilement uniquement les tests nécessaires pour vérifier les modifications du code local. Dans un modèle de déploiement direct vers la production, cela empêche les bogues d'atteindre les utilisateurs finaux. Lorsque plusieurs équipes sont impliquées dans un projet, cela évite de perdre du temps à d'autres équipes qui doivent dépanner et résoudre des problèmes qui auraient pu être évités si les tests appropriés avaient été exécutés avant la validation du code.

Intégration et complément des outils de pipeline

Les outils ne fonctionnent pas si vous ne pouvez pas les intégrer facilement dans votre chaîne d'outils existante. Parasoft Jtest prend en charge les projets qui sont dans le contrôle de source Git ou SVN, ainsi que d'autres systèmes de contrôle de source. L'intégration IDE existe pour Eclipse et IntelliJ. Jtest fournit des plugins Maven et Gradle qui peuvent être intégrés dans une tâche de build CI qui exécute des tests dans le cadre d'une build Maven ou Gradle.

Ces plugins peuvent être configurés pour automatiser entièrement une suite de tests en déterminant quel code a changé depuis la construction de base, qui est souvent configurée pour être la dernière version nocturne, puis en déterminant quels tests doivent être exécutés pour exercer ce code, puis exécutez juste ce sous-ensemble de tests. Cela permet à une équipe de configurer un travail CI qui n'exécute que des tests basés sur les modifications de code les plus récentes, ce qui leur permet de réduire le temps nécessaire pour exécuter un travail CI qui peut passer de quelques heures à quelques minutes.

En tant que meilleure pratique, les équipes peuvent exécuter la suite complète de tests unitaires tous les soirs et tirer parti de l'analyse d'impact des tests dans les versions quotidiennes (intermédiaires). Cela rend Parasoft Jtest particulièrement avantageux pour les équipes disposant de suites de tests de longue durée, qui peuvent obtenir un véritable CI en obtenant les résultats de tests pertinents dans les minutes qui suivent la validation du code. Sans pouvoir le faire, de mauvaises modifications de code peuvent introduire des régressions qui ne sont pas détectées aussi rapidement et peuvent donc se faufiler dans la production ou interférer avec le travail effectué par d'autres membres de l'équipe.

En concentrant les ressources sur exactement ce qui doit être testé, les équipes de développement peuvent exécuter rapidement et efficacement des tests pour vérifier le code qu'elles enregistrent en permanence, en détectant les bogues et les vulnérabilités de sécurité avant même qu'ils n'atteignent la version.

Par Kapil Bhandari

Kapil est chef de produit chez Parasoft et se concentre sur Parasoft Jtest. Kapil a occupé plusieurs postes techniques allant d'ingénieur logiciel à chef de développement, avant de passer à la gestion de produit.