code refactoring what you need know about it
Comprendre le refactoring de code: le point de vue d'un testeur
Le terme «Refactoring» est principalement utilisé pour indiquer le nettoyage / la refonte du code requis.
Dans ce didacticiel, nous comprendrons la définition de la refactorisation, discuterons de la nécessité de refactoriser le code et examinerons l'impact du refactoring du code sur divers membres de l'équipe de projet. Nous discuterons également de la réponse à la question la plus importante - En tant que testeur, pourquoi avez-vous besoin de connaître le refactoring?
De plus, nous discuterons également de quelques études de cas pour clarifier le concept.
Ce que vous apprendrez:
- Introduction au refactoring
- Besoin de refactorisation du code
- Pourquoi un AQ doit-il connaître le refactoring?
- Études de cas
- Conclusion
- lecture recommandée
Introduction au refactoring
Pour commencer, comprenons d'abord ce qu'est réellement le refactoring.
La refactorisation est essentiellement une pratique ou un processus d'amélioration du code et / ou de la base de données tout en conservant la fonctionnalité existante. L'idée est de transformer le code inefficace et trop compliqué en un code plus efficace, de préférence plus simple et plus facile.
La refactorisation du code a également pris de l'ampleur avec plus d'équipes maintenant en suivant l'approche de développement logiciel agile. Les équipes de projet ont souvent peu de temps pour implémenter de nouvelles fonctionnalités ou étendre les fonctionnalités des fonctionnalités existantes et du code propre. Le code, qui est facile à comprendre et à maintenir, permet certainement de respecter la date limite d'itération.
Besoin de refactorisation du code
Si nous conservons la fonctionnalité d'origine de l'application ou du module, une question se pose: Pourquoi nous embêtons-nous même à refactoriser? Eh bien, il existe de nombreuses raisons pour lesquelles un module ou un morceau de code particulier peut avoir besoin d'être refactorisé, comme:
- Le code sent
- Dette technique
- Approche de développement logiciel agile, etc.
Nous discuterons ces points en détail dans les sections suivantes.
# 1) Odeurs de code:
Nous pouvons tous comprendre que lorsque la nourriture commence à sentir, cela indique qu'elle va probablement mal tourner - c'est également vrai pour le code! Les odeurs de code indiquent qu'un problème très sérieux peut exister dans le code.
Voici quelques odeurs de code courantes:
- Présence de code redondant ou identique.
- Une variable déclarée qui n'est utilisée nulle part dans le reste du code.
- Conception de code trop compliquée.
- Classe de code qui fait trop peu et ne justifie pas l'existence de la classe définie. Ces classes sont connues sous le nom de classe paresseuse ou de chargeur libre.
- L'existence d'un trop grand nombre de conditions et de boucles susceptibles d'être décomposées et simplifiées.
- Code construit de manière à ce qu'une modification dans une partie du code nécessite que la modification soit également implémentée aux autres endroits.
Les odeurs de code deviennent plus apparentes avec le temps. À mesure que l'application ou le système se développe, ces odeurs de code finissent par affecter le développement du code, la maintenance et même les performances du système dans des scénarios extrêmes.
# 2) Dette technique:
Lors du développement d'un logiciel, pendant le temps limité et les ressources disponibles, nous pouvons souvent prendre des raccourcis pour obtenir les résultats souhaités.
Considérez une fonctionnalité qui doit être ajoutée à un module existant. Après discussion, l'équipe réduit 2 approches pour ajouter cette fonctionnalité. L'approche A, qui nécessite 2 sprints à livrer, sera l'approche à long terme approuvée. L'approche B ne prend que 5 jours pour livrer est un piratage codé en dur désordonné qui est conçu pour simplement entretenir le module à court terme.
Si l'équipe est sous pression pour fournir la fonctionnalité dans un temps limité, elle peut accepter de suivre l'approche B pour le moment et d'ajouter l'approche A dans le backlog pour l'avenir. En faisant cela, cette équipe vient de se créer une dette technique.
En termes simples, la dette technique dans le développement de logiciels fait référence aux retouches supplémentaires ou aux frais généraux nécessaires pour mettre en place les correctifs appropriés ou faire les choses de la «bonne manière».
Les systèmes hérités ont tendance à acquérir une dette technique énorme au fil du temps, ce qui peut à son tour rendre l'application vulnérable à l'échec et difficile à prendre en charge et à maintenir.
Lire la suite=> Qu'est-ce que le département technique
# 3) En suivant une approche de développement logiciel agile:
L'approche de développement logiciel agile préconise le développement incrémental. Sans un code propre, bien structuré et facile à maintenir, il ne serait pas possible pour les équipes d'étendre le code existant à chaque itération. Si le code est modifié sans refactorisation appropriée, cela peut contribuer à des odeurs de code ou à une dette technique.
Cette relation est illustrée dans le diagramme ci-dessous
Lecture recommandée => Principaux outils d'analyse de code
Pourquoi un AQ doit-il connaître le refactoring?
Tout ce dont nous avons discuté jusqu'à présent dans ce tutoriel semble être lié au codage et ressemble au genre de choses dont un développeur devrait s'inquiéter.
Alors, pourquoi discutons-nous de ce concept indépendant dans la communauté d'aide de Software Testing? Continuez à lire le reste de ce didacticiel pour obtenir la réponse à cette question.
# 1) Pour les testeurs / développeurs unitaires
Lors de la refactorisation du code, à mesure que le nouveau code est inséré, les anciennes classes sont mises à jour, de nouvelles classes sont ajoutées et les tests unitaires existants peuvent désormais échouer. De plus, pour les systèmes hérités, il se peut qu'aucun test unitaire ne soit implémenté. Ces nouveaux tests unitaires devront être créés et mis en place à partir de zéro dans la majorité des cas.
# 2) Pour les testeurs
Lorsqu'une fonctionnalité est en cours de refactorisation (étant donné que nous n'ajoutons aucune nouvelle fonctionnalité), il est entendu qu'une fois les modifications requises effectuées, la majorité des fonctionnalités pour l'utilisateur final doivent rester les mêmes.
- En tant que testeur, la refactorisation du code se traduit approximativement par = des tests approfondis + des tests de régression. Des tests approfondis doivent inclure tous les flux d'utilisateurs existants pour garantir que toutes les fonctionnalités fonctionnent comme avant. Les tests de régression de l'application entière (ou des zones touchées) est nécessaire pour garantir que la mise à niveau d'un module n'a pas interrompu involontairement la fonctionnalité des autres modules.
- Les tests d'acceptation des utilisateurs seront importants et ces tests doivent réussir avant que la construction puisse être déclarée prête à être publiée.
- De plus, tout autre test requis comme les tests de charge, test de sécurité etc. devront également être mis en œuvre au besoin.
# 3) Ingénieurs de test d'automatisation
La refactorisation du code peut entraîner l'échec des scripts d'automatisation fonctionnels et non fonctionnels.
Cela peut se produire pour les raisons suivantes:
- Si les objets de page changent dans le cadre de l'effort de refactorisation et si vos scripts d'automatisation Selenium reposent sur les objets de page, les scripts échoueront et devront être mis à jour.
- S'il y avait des modifications mineures, il redirige celles qui ont été ajoutées ou supprimées lors de la refactorisation, et les scripts d'automatisation existants échoueraient et devraient être mis à jour
Il est recommandé que les tests d'automatisation fonctionnelle ne soient mis en place qu'une fois qu'une fonctionnalité est stable, sinon cela entraînera beaucoup de retouches à mesure que la fonctionnalité évolue.
En tant que développeur de tests d'automatisation, les ingénieurs de test d'automatisation doivent également penser comme un développeur et viser à créer un code propre et facile à maintenir. La plupart des IDE comme IntelliJ IDEA, Eclipse, etc., incluent un menu de refactoring intégré avec des méthodes de refactoring couramment utilisées pour une référence facile.
Vous trouverez ci-dessous une capture d'écran du menu de refactoring dans IntelliJ IDEA (Community Edition).
Questions et réponses d'entretien d'Oracle pour les expérimentés
# 4) Pour les fils de test / fils d'assurance qualité
- Les responsables des tests / responsables de l'assurance qualité peuvent être tenus de travailler avec le reste de l'équipe, y compris les développeurs, les analystes de produits et peut-être même les parties prenantes, pour s'assurer que la planification des tests pour de tels projets est effectuée avec soin.
- Il est important de comprendre la fonctionnalité existante. Sur la base des fonctionnalités existantes, les analyses de rentabilisation, les flux d'utilisateurs et les tests d'acceptation des utilisateurs doivent être documentés. Lorsqu'un code refactorisé est testé, tous ces scénarios doivent être validés, ainsi que des tests de régression des zones impactées.
- Soyez proactif lors de la planification de l'approche de test et plans de test . Si vous prévoyez l'exigence de plusieurs environnements de test ou de nouveaux outils de test, veuillez envoyer la demande tôt pour éviter tout retard une fois la phase de test commencée.
- N'hésitez pas à impliquer des membres non membres de l'équipe du projet ou des utilisateurs finaux pour contribuer aux tests.
Études de cas
Nous allons maintenant discuter de quelques études de cas réelles dans lesquelles j'ai eu l'occasion de travailler directement ou de contribuer indirectement.
Étude de cas n ° 1
Tâche: Refactoriser un module pour remplacer les valeurs codées en dur par des variables et ajouter des commentaires pour le nouvel outil automatisé de génération de documentation technique.
Défis :Aucun défi majeur. Le module était nouveau, avait documenté les exigences fonctionnelles et d'acceptation des utilisateurs, les flux d'utilisateurs et les cas de test. Des tests unitaires ont été mis en place lors du lancement initial lui-même.
Approche de test :Les cas de test pour le module en cours de refactorisation et les zones impactées relativement connues ont été exécutés. Tous les défauts ont été signalés et résolus avant la publication.
Étude de cas n ° 2
Tâche :Refactoriser la procédure stockée existante pour faciliter la mise à l'échelle de l'application.
La procédure stockée dans ce scénario était une procédure stockée plus ancienne qui a été conçue il y a quelques années, en gardant à l'esprit l'exigence que l'application utilise sa procédure stockée en tant qu'application interne avec moins de 10 sessions simultanées.
Désormais, l'entreprise souhaitait commercialiser cette application en tant que logiciel en tant que service (SaaS), avec le volume prévu de 300 sessions simultanées initialement.
L'équipe a effectué quelques tests de charge initiaux et a conclu que le système se rompt avec une charge de 25 sessions simultanées. L'équipe a examiné le code et a recommandé de refactoriser une procédure stockée principale existante qui permettrait à l'application d'évoluer et de prendre en charge jusqu'à 500 sessions simultanées sans interruption.
Certains problèmes identifiés avec cette procédure stockée concernaient plusieurs sous-requêtes dans une même requête, des jointures lourdes avec des vues au lieu de tables, l'utilisation de select * au lieu de sélectionner une colonne spécifique, etc. En raison de ces problèmes de codage, l'application récupérait plus de données que cela était vraiment nécessaire, ce qui a entraîné un ralentissement de l'application et finalement une panne.
Défis:
# 1) Chef de projet / Analyste produit
- Rassemblement des exigences - Étant donné que cette procédure stockée était un code hérité, aucune exigence documentée n'était requise lors de la conception initiale du module. De plus, pour les itérations effectuées au cours des dernières années, il n'y avait pas de journal des modifications pour indiquer les règles métier et la logique ajoutées ou supprimées du module.
- Calendrier du projet - Étant donné que les exigences n'étaient pas clairement définies et que les dépendances des codes n'étaient pas encore entièrement identifiées, il était difficile de communiquer le calendrier provisoire.
# 2) Pour les développeurs
- Absence d'exigences et de règles commerciales claires.
- Nettoyer le code sans perdre ses fonctionnalités.
- Zones impactées et / ou dépendances de code inconnues.
- Impossible de fournir des estimations de temps de développement concrètes.
- Besoin de créer de nouveaux tests unitaires.
# 3) Pour les testeurs
- Le manque d'exigences claires et de règles métier a un impact sur la planification des tests.
- Les zones impactées inconnues ont un impact sur la planification des tests, en particulier pour les tests de régression.
- Impossible de fournir des estimations de test concrètes.
# 4) Parties prenantes
- Absence d'exigences clairement documentées et / ou de flux d'utilisateurs + délais serrés = Risque d'échec plus élevé.
L'approche suivie par l'équipe pour atténuer les risques et contourner les défis :
(i) L'équipe a suivi une approche collaborative pour recueillir les exigences : Le chef de projet / analyste de produit et les testeurs ont travaillé en étroite collaboration avec les utilisateurs finaux internes pour comprendre et documenter les principales fonctionnalités et le flux d'utilisateurs.
Les développeurs ont également examiné le code et ajouté des informations pertinentes au document sur les exigences. Cela a été fait avant le jour du début du sprint.
(ii) L'environnement de test alternatif a été créé pour tester le changement mis en œuvre : Appelons ces environnements Gamma et Phi. Gamma aurait l'ancien code et Phi aurait la dernière procédure stockée refactorisée déployée à tout moment.
Avoir 2 environnements de test en parallèle, recréant presque l'approche avant - et - après, a permis à l'équipe de faire des tests plus approfondis et exploratoires en comparant le comportement dans ces 2 environnements de test, ils ont pu identifier les bogues probables.
L'équipe a fourni les exigences pour un autre environnement de test qui a été fourni avant la date de début du sprint.
(iii) Utilisateurs finaux et parties prenantes impliqués dans les tests dès le début : Tous les problèmes évidents ont été détectés et signalés rapidement, ce qui a laissé plus de temps à l'équipe pour déployer et tester le correctif requis.
(iv) Définir les critères de sortie et y adhérer: Les critères de sortie ont été définis lors des étapes de planification initiales - 80% des flux d'utilisateurs testés, aucun bogue critique non résolu, démonstration et approbation des parties prenantes avant la sortie.
(v) Fixation d'une date de sortie provisoire: Fixer une date de sortie alignée et motiver l'équipe à travailler vers un point final commun. Sur la base de la portée du projet, il a été recommandé par l'équipe de suivre un sprint de 3 semaines au lieu d'un sprint régulier de 2 semaines pour laisser suffisamment de temps à l'équipe pour exécuter le projet.
Conclusion
Pour résumer, la refactorisation du code est un processus pour nettoyer / simplifier la conception d'un module sans changer sa fonctionnalité. Le processus de refactoring peut être simple, comme ajouter des commentaires, ajouter une indentation correcte, supprimer une variable statique, etc. ou peut être compliqué pour les systèmes hérités complexes.
Un module ou un morceau de code particulier peut devoir être refactorisé en raison des odeurs de code, de la dette technique ou en suivant une approche de développement logiciel agile.
Pour les testeurs, la refactorisation du code se traduit approximativement par = des tests approfondis + des tests de régression.
Des tests approfondis sont nécessaires pour tester tous les flux d'utilisateurs existants afin de s'assurer que toutes les fonctionnalités fonctionnent comme avant. Des tests de régression de l'ensemble de l'application (ou des zones impactées) sont nécessaires pour s'assurer que la mise à niveau d'un module n'a pas interrompu involontairement la fonctionnalité des autres modules.
Les responsables des tests / responsables de l'assurance qualité peuvent être amenés à travailler avec le reste de l'équipe, y compris les développeurs, les analystes de produits, en particulier pour les projets existants. Soyez proactif lors de la planification de l'approche de test et des plans de test. Si vous prévoyez la nécessité de plusieurs environnements de test ou de nouveaux outils de test, veuillez envoyer la demande dès le début pour éviter tout retard une fois la phase de test commencée.
A propos de l'auteur: Ce didacticiel informatif est écrit par Neha B. Elle travaille actuellement en tant que responsable de l'assurance qualité et se spécialise dans la direction et la gestion d'équipes d'assurance qualité internes et offshore.
Avez-vous travaillé sur un projet stimulant qui impliquait la refactorisation de code ou d'un module / application? Si oui, n'hésitez pas à partager vos expériences dans la section commentaires pour que nos collègues testeurs puissent apprendre.
lecture recommandée
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- TOP 40 des outils d'analyse de code statique (meilleurs outils d'analyse de code source)
- La clé du succès des tests unitaires - Comment les développeurs testent leur propre code?
- Top 10 des outils de révision de code les plus populaires pour les développeurs et les testeurs
- Travail d'indépendant de rédacteur de contenu technique de test de logiciels
- Téléchargement du livre électronique sur les tests
- 11 meilleurs outils d'automatisation pour tester les applications Android (outils de test des applications Android)
- Les différences entre les tests unitaires, les tests d'intégration et les tests fonctionnels