Article
· Fév 22, 2023 13m de lecture

Tests unitaires : Qualité de votre code ObjectScript

Dans les principales méthodologies de développement de logiciels, il y a toujours un chapitre consacré aux tests. Il s'agit d'une approche obligatoire pour obtenir la qualité des livraisons de manière continue.

On distingue deux types de tests:

  1. White Box Test : Ce sont des tests qui examinent la qualité du code source et des fonctionnalités de l'application. Dans ce type de test, nous avons :
    1. Analyse statique : on utilise des solutions d'analyse statique (il n'y a pas d'exécution de la fonctionnalité au moment du test) du code source, où les modèles de nommage, l'indentation, les variables déclarées et inutilisées, l'indice de couplage entre les composants, entre autres critères définis, sont évalués dans les solutions d'analyse. En général, dans l'environnement de développement, les lignes de code source présentant des problèmes de qualité sont signalées, ce qui permet au développeur d'agir pour résoudre le problème.
    2. Test unitaire : des classes de test ("Unité de test") sont créées, une pour chaque thème de fonctionnalité (Gestion des clients, Collecte des transactions, etc.), regroupées en Suites de test (ensemble d'unités de test), une suite pour chaque module d'application (Module d'enregistrement, Module de vente, etc.) ou pour l'application dans son ensemble. En général, un rapport HTML est émis avec les résultats obtenus.
  2. Black Box Test: tests effectués sur le binaire de l'application, sans accès au code source de l'application. Dans ce type, nous avons :
    1. Test de performance : Des scripts de chargement de données et d'exécution sont définis pour les principales fonctionnalités afin d'évaluer si l'application et l'environnement d'exécution supporteront le nombre de transactions et d'utilisateurs prévus.
    2. Test de pénétration - PenTest : des solutions d'analyse de vulnérabilité sont utilisées pour les adresses IP et les ports de l'application, les produits qui hébergent la solution (serveur web, application et base de données) et les points de terminaison de l'application (API, services web, répertoires d'échange de fichiers et autres points d'interaction). Généralement, un rapport PDF est émis avec les vulnérabilités trouvées.
    3. Tests fonctionnels : Les analystes et les testeurs écrivent et exécutent plusieurs scénarios de test à partir des interfaces visuelles de l'application, dans le but d'identifier les failles fonctionnelles (fonctionnalité présentant une erreur du point de vue de l'utilisateur final). Il existe aujourd'hui des solutions qui permettent également d'automatiser ces tests à partir des interfaces visuelles.

Un objectif important de la discipline des tests est de trouver le point idéal de couverture des tests (fonctionnalités couvertes par les tests). Dans les projets auxquels je participe, l'objectif est d'atteindre au moins 75% des fonctionnalités. Le grand secret est de concentrer vos tests sur la couche métier de l'application, car c'est là que se trouvent les règles métier et la mise en œuvre des exigences fonctionnelles fournies à l'utilisateur final. Les différentes interfaces visuelles et les points d'intégration finissent toujours par nécessiter la couche métier. De cette façon, en automatisant les tests de la couche fonctionnelle, la couverture des tests aura un taux pertinent.

Cet article présente comment automatiser les tests unitaires de la couche métier de votre application IRIS, afin de démontrer comment obtenir de bons taux de couverture des tests et une bonne qualité des applications IRIS livrées à l'utilisateur final.

Téléchargement de l'application à tester

Allez sur https://openexchange.intersystems.com/package/global-mindmap et cliquez sur le bouton Github. Suivez les étapes suivantes :

  1. Clonage du projet

    $ git clone https://github.com/yurimarx/global-mindmap.git

  1. Faites le docker build dans le dossier racine du projet :
$ docker-compose build
  1. Executer le conteneur Docker Container:
$ docker-compose up -d

Découvrez l'application en action

Maintenant, passez aux tests

La classe affaires à tester

 

Classe Affaires Cible à tester

La classe affaires dispose de 3 fonctionnalités à tester :

  1. StoreMindmapNode : fonctionnalité utilisée pour enregistrer les données d'un nœud de carte heuristique dans la base de données sous forme de globales.
  2. GetMindmap : fonctionnalité utilisée pour retourner tous les noeuds de la carte mentale stockés dans les globales, c'est-à-dire la carte mentale dans son ensemble.
  3. DeleteMindmapNode : fonctionnalité utilisée pour supprimer un nœud de carte mentale de la base de données (supprime le nœud de globale qui stocke le nœud).

Création de la suite de tests - Un ensemble de cas de test

Il suffit de créer un répertoire à la racine du répertoire src, avec le nom de la suite de test, dans cet exemple le nom créé était UnitTests.

Création des classes de test de la suite de tests

Vous devez créer des classes de test qui héritent de %UnitTest.TestCase. Le nom de la classe, comme une bonne pratique, devrait être TestClassNameToBeTested + Test. Dans notre exemple, la classe s'appelle GlobalMindMapServiceTest. Découvrez le contenu de la classe :

 

Classe de cas à tester

Remarquez que pour chaque fonctionnalité à tester, nous avons une méthode avec la convention de dénomination suivante : Test +Nom de la méthode à tester. Il est important que chaque méthode de test fasse tout ce qui est nécessaire à l'exécution du test. Dans le test de suppression, par exemple, un enregistrement est d'abord créé, qui sera utilisé pour être supprimé et ainsi tester si la suppression fonctionne.

Pour chaque méthode, il doit y avoir au moins un appel à $$$Assert..... Cette macro est l'exécution et l'enregistrement de la condition de test elle-même. Dans notre exemple, nous utilisons $$$AssertEquals dans toutes les méthodes. Dans ce cas, si la condition de test est égale au résultat de l'exécution de la méthode métier, le test est marqué comme réussi, sinon il est marqué comme non réussi. Il existe plusieurs options Assert, voir plus de détails sur https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls....

Il est également possible d'utiliser la méthode OnBeforeAllTests pour créer les données et les conditions nécessaires aux tests et d'utiliser OnAfterAllTests pour nettoyer les données et les environnements et les ramener à leur état initial.

Exécution des tests

Une fois la suite et les cas de test prêts, il est temps d'effectuer les tests. Pour cela, vous devez accéder au Terminal, dans l'espace de nom où se trouvent les classes, consultez les étapes de l'exemple dans cet article :

  1. Sur Terminal, espace de nom IRISAPP, il faut aller dans l'espace de nom qui contient les classes d'affaires et de test :

    USER>zn "IRISAPP"

  1. Il est nécessaire de pointer vers le dossier où se trouve le dossier Test Suite (dans l'exemple, il s'agit du dossier UnitTests dans src)
IRISAPP>Set ^UnitTestRoot="/opt/irisbuild/src"
  1. Exécutez les tests unitaires
IRISAPP>do ##class(%UnitTest.Manager).RunTest("UnitTests")
  1. Découvrez les résultats ici: http://localhost:52773/csp/sys/%25UnitTest.Portal.Indices.cls?Index=1&$NAMESPACE=IRISAPP

Analyse des résultats

Le rapport de l'étape précédente revient dans cette mise en page :

Il est possible de savoir ce qui a réussi (vert) et ce qui a échoué (rouge). En cliquant sur le rouge, il est possible de savoir où l'erreur s'est produite :

Il ne reste plus qu'à appliquer les corrections.

Si vous avez aimé l'exemple d'application, votez pour elle à Global Contest.

Discussion (0)2
Connectez-vous ou inscrivez-vous pour continuer