Objectives
After completing this lesson, you will be able to:
- Implémentez une classe de test.
- Exécutez un test unitaire ABAP.
Unité ABAP
Tests de module
Chaque fois que les programmeurs écrivent ou changent de code, il y a de fortes chances qu'ils introduisent des erreurs de programmation. Par conséquent, les tests sont une partie cruciale de chaque projet de développement.
Dans la programmation moderne, le code est structuré en classes et méthodes réutilisables. Pour détecter et localiser les erreurs de programmation potentielles, un test approfondi de chaque unité de modularisation est nécessaire.
Prenons un exemple.
ABAP Unit - Implémentation de tests de module dans ABAP
ABAP Unit est une technique qui vous permet d'implémenter des tests de module avec le langage ABAP. Vous pouvez déclencher l'exécution du test manuellement pendant le développement, mais aussi automatiquement à plus grande échelle et régulièrement.
Les tests ABAP Unit sont implémentés en tant que méthodes de classes ABAP spécialement désignées. Ces méthodes de test servent de scripts de test, avec lesquels le code testé peut être exécuté et avec lequel les résultats peuvent être évalués.
Poursuivons avec notre exemple.
Il est très important qu'une fois les tests effectués, vous puissiez les effectuer à tout moment et aussi souvent que vous le souhaitez : avant l'expédition initiale, après avoir appliqué des modifications au code productif ou pour l'analyse des erreurs lorsqu'un utilisateur signale un problème. Et, l'exécution des tests ne vous coûte que quelques clics de souris.
Fonctionnalités importantes d'ABAP Unit
Classes de test unitaire
L'option FOR TESTING dans la définition de classe distingue une classe de test d'une classe ABAP ordinaire. L'option est disponible pour les classes locales ainsi que pour les classes globales.
L'ajout, NIVEAU DE RISQUE, est utilisé pour affecter un niveau de risque au test. Si l'option est manquante, le niveau de risque CRITICAL est utilisé par défaut.
Les options centrales au niveau du mandant peuvent empêcher l'exécution de tests avec un certain niveau de risque.
Les valeurs de niveau de risque suivantes sont disponibles :
- CRITIQUE
Un test modifie les options système ou les données du Customizing.
- DANGEREUX
Un test modifie les données persistantes.
- HARMLESS
Un test ne modifie pas les options système ni les données persistantes.
L'option DURATION supplémentaire indique la durée d'exécution attendue. Les options centrales au niveau du mandant peuvent être utilisées pour définir des limites de durée d'exécution supérieures pour les trois valeurs.
Les valeurs de durée suivantes sont disponibles :
- COURT
Un temps d'exécution imperceptible de quelques secondes est attendu.
- MOYENNE
Un temps d'exécution notable d'environ une minute est attendu.
- LONG
Un temps d'exécution très perceptible de plus d'une minute est attendu.
Une classe de test peut avoir deux types de méthodes :
- Méthodes de test
Les méthodes de test sont définies avec l'option FOR TESTING après le nom de la méthode. Chaque méthode de test représente un test. Le framework ABAP Unit exécute ce test en appelant la méthode de test associée. Les méthodes de test ne doivent pas avoir de paramètres.
- Méthodes d'aide
Les méthodes d'aide sont des méthodes ordinaires de la classe de test. Elles ne sont pas appelées par le framework ABAP Unit. Vous pouvez utiliser des méthodes d'aide pour structurer le code de vos méthodes de test ou si vous voulez réutiliser la même fonctionnalité dans plusieurs méthodes de test. Les méthodes d'aide peuvent avoir un nombre quelconque de paramètres.
Remarque
Le framework ABAP Unit peut appeler toutes les méthodes de test, même si leur visibilité est définie sur PRIVÉE. En fait, il est recommandé de définir des méthodes de test dans la section privée de la classe de test pour s'assurer que les classes de test ne sont pas appelées directement n'importe où dans le code.
Une classe de test doit contenir au moins une méthode de test. Une méthode de test ne doit pas avoir de paramètres.
Lors de l'exécution des tests d'une classe de test, la structure ABAP Unit appelle tous les tests de la classe de test dans un ordre indéterminé.
Si vous voulez définir des classes de test locales dans une classe ABAP globale, vous disposez d'un emplacement dédié. Alors que les classes locales ordinaires sont définies dans l'onglet Types locaux, les classes de test locales doivent être définies dans l'onglet Classes de test.
Comme illustré dans la figure, pour générer la partie définition et la partie implémentation d'une classe de test locale, ADT propose le modèle de code testClass.
Dans la démonstration Comment définir et implémenter une classe de test, vous allez apprendre à appeler ce modèle de code.
Implémentation du test unitaire
Classe de service CL_ABAP_UNIT_ASSERT
En général, l'implémentation d'une méthode de test a la structure suivante :
- Exécuter le codage productif sous test
- Analyser le résultat
- Signaler un résultat inattendu au framework ABAP Unit
Pour l'étape 3, le framework ABAP Unit fournit la classe de service globale CL_ABAP_UNIT_ASSERT. Les méthodes de test appellent les méthodes statiques de cette classe pour signaler les erreurs et influencer l'exécution du test (par exemple, ignorer un ou plusieurs tests car les conditions préalables ne sont pas remplies).
- Échec de la méthode ( ) signale une erreur inconditionnelle. En règle générale, un appel de cette méthode est entouré d'une structure de contrôle comme IF … ENDIF. ou TRY … ENDTRY pour garantir qu'elle n'est atteinte que sous une condition.
- Les méthodes commençant par assert_ vérifient une attente donnée et signalent une erreur si cette attente n'est pas satisfaite.
- La méthode assert_equals( ), par exemple, compare le contenu de deux objets de données et signale une erreur si elles diffèrent.
- La méthode assert_différences( ) fait de même mais signale une erreur si les objets de données ont le même contenu.
Echec des paramètres de la méthode ( )
Regardez la vidéo suivante pour en savoir plus.
Paramètres des méthodes d'assertion
Toutes les méthodes d'assertion ont des paramètres d'importation facultatifs MSG, LEVEL et QUIT, qui ont toujours la même signification que dans la méthode fail( ).
En outre, la plupart des méthodes d'assertion ont un paramètre d'importation ACT pour l'objet de données à vérifier.
Les méthodes de comparaison, comme assert_equals( ), assert_différences( ), etc., ont également un paramètre EXP pour la valeur attendue.
Comment définir et implémenter une classe de test
Cette démonstration vous apprend à créer et implémenter une classe de test locale.
Exécution du test unitaire
Il existe deux façons d'exécuter des tests ABAP Unit : les tests interactifs pendant les tests de développement et les tests en masse avec ABAP Test Cockpit.
Regardez la vidéo suivante pour en savoir plus sur l'exécution du test unitaire.
Résultats du test ABAP Unit
Dans ADT, le dernier résultat du test unitaire ABAP est affiché dans la vue ABAP Unit.
La synthèse en haut affiche le nombre total de méthodes de test qui ont été exécutées et la durée totale du test en millisecondes.
Utilisez les cases à cocher de la synthèse pour filtrer l'affichage des résultats : uniquement les tests qui ont échoué, uniquement les tests avec des avertissements, uniquement les tests qui se sont terminés avec succès, etc.
Le résultat lui-même est affiché sous forme d'arborescence avec les objets du Repository au-dessus, par exemple, la classe globale. Les nœuds du deuxième niveau représentent les classes de test locales et les points d'extrémité correspondent aux méthodes de test. Les icônes vous aident à distinguer les tests réussis, les échecs, etc.
Un clic gauche sélectionne la méthode de test et affiche les détails à droite. Dans l'exemple, vous pouvez voir le degré de gravité (Erreur d'assertion critique pour le degré de gravité moyen), la valeur du paramètre MSG ('Aucune exception') et la valeur du paramètre DETAILS (le texte est développé sous Détails).
Exécution d'un test unitaire et analyse du résultat
Cette démonstration vous apprend à exécuter les tests de module et à analyser les résultats.
Tester les présentoirs et les prérequis
Méthodes pour appareils de test
Parfois, un test nécessite une certaine configuration avant de pouvoir s'exécuter correctement. Une telle configuration de test est appelée monture d'essai. Un dispositif de test peut être constitué de données de test, d'objets de test et de ressources.
Pour créer et supprimer des présentoirs, vous pouvez implémenter des méthodes supplémentaires dans une classe de test. Ces méthodes ont des noms prédéfinis et sont automatiquement appelées par l'environnement d'exécution ABAP lors de l'exécution du test.
Les méthodes de présentoir suivantes existent :
- SETUP
Cette méthode d'instance est appelée avant chaque test de la classe de test. Utilisez cette méthode pour les présentoirs que vous voulez recréer pour chaque test.
- TEARDOWN
Cette méthode d'instance est appelée après chaque test de la classe de test. Utilisez cette méthode pour annuler les modifications que vous avez apportées dans la méthode SETUP. L'utilisation de TEARDOWN est particulièrement importante si SETUP apporte des modifications aux données persistantes (configuration du système, Customizing, données de base, etc.).
- CLASS_SETUP
Cette méthode statique est exécutée une fois avant le premier test de la classe de test. Utilisez cette méthode uniquement pour les présentoirs qui prennent du temps et pour lesquels vous êtes sûr que les options ne sont modifiées par aucune des méthodes de test.
- CLASS_TEARDOWN
Cette méthode statique est exécutée une fois après le dernier test de la classe de test. Utilisez cette méthode pour annuler les modifications que vous avez effectuées dans la méthode CLASS_SETUP.
Logique d'exécution du test unitaire ABAP
Ce graphique illustre l'exécution du programme ABAP UNIT pour une seule classe de test.
- Dans un premier temps, la classe de test est chargée dans la mémoire de programme. Si la classe de test contient un constructeur statique (méthode statique CLASS_CONSTRUCTOR), cette méthode est exécutée comme d'habitude.
- Ensuite, les tests de cette classe de test sont effectués. Chaque test commence par la création d'une instance de la classe de test. Si la classe de test contient un constructeur d'instance (méthode CONSTRUCTOR), elle est exécutée comme d'habitude.
- Ensuite, le framework ABAP Unit appelle la méthode de test.
- Après le test, l'instance est rejetée.
S'il existe plusieurs méthodes de test dans la classe de test, une nouvelle instance est créée pour chaque test.
Après la dernière méthode de test, le traitement de cette classe de test est terminé et la structure continue avec la classe de test suivante, le cas échéant.
Modèle de phase du test unitaire ABAP
Ce graphique illustre le modèle de phase pour les tests ABAP Unit, c'est-à-dire les dates/heures auxquelles la structure appelle des méthodes de présentoir.
CLASS_SETUP n'est appelé qu'une seule fois, après le constructeur statique et avant le premier test.
CLASS_TEARDOWN est appelé avant que la structure ne lance le traitement de la classe de test suivante.
SETUP est appelé après le constructeur d'instance et avant l'exécution du test.
TEARDOWN est appelé avant que la structure rejette l'instance de classe de test.
Signalement des conditions préalables manquantes
Vous avez déjà appris à utiliser les méthodes de la classe de service CL_ABAP_UNIT_ASSERT pour signaler les tests ayant échoué.
Mais que devez-vous faire en cas de condition préalable manquante, par exemple, des autorisations manquantes ? Ou une situation où une méthode SETUP a des problèmes pour préparer le test ?
Pour ces situations, la classe CL_ABAP_UNIT_ASSERT contient une méthode skip( ) et plusieurs méthodes commençant par ASSUME_.
Les méthodes fonctionnent de manière assez similaire à l'échec ( ) et aux méthodes d'assertion, mais elles ont une apparence différente dans le résultat du test UNIT. Cela facilite la distinction entre les erreurs dans le codage testé et les erreurs dans la configuration du système ou la conception de test.
Prenons un exemple :
La méthode test_with_fail( ) appelle la méthode cl_abap_unit_assert=>fail( ). Cette méthode est comptée comme test échoué et la trace d'échec pour cette méthode affiche Erreur d'assertion critique devant le texte du message.
La méthode test_with_skip( ) appelle la méthode cl_abap_unit_assert=>skip( ). Cette méthode est comptée comme un test interrompu et la trace des échecs pour cette méthode affiche les conditions préalables manquantes devant le texte du message.
Remarque
Il n'y a pas de paramètres QUIT et LEVEL dans les méthodes skip( ) et les méthodes assume-method. S'il manque des conditions préalables, il ne sert à rien de poursuivre le test et nous ne faisons pas de distinction entre les différents degrés de gravité.
Comment exécuter un test unitaire complexe avec SETUP
Cette démonstration vous apprend à exécuter un test plus complexe contenant une méthode de configuration.
Implémentation et exécution d'un test unitaire ABAP
Vous remarquez que quelque chose ne va pas avec la sortie de votre code. En particulier, la date du prochain vol de fret disponible semble incorrecte. Vous définissez et implémentez un test unitaire ABAP pour la méthode find_cargo_flight de la classe locale lcl_Carrier afin d'analyser plus en détail ce problème.
Tâche 1: Copier modèle (facultatif)
Copiez la classe de modèle /LRN/CL_S4D401_ATS_CHECKED. Si vous avez terminé l'exercice précédent, vous pouvez ignorer cette tâche et continuer à modifier votre classe ZCL_##_SOLUTION.
Étapes
Copiez la classe /LRN/CL_S4D401_ATS_CHECKED dans une classe de votre propre package (nom proposé : ZCL_##_SOLUTION, ## correspondant à votre numéro de groupe).
Dans l'explorateur de projet, cliquez avec le bouton droit de la souris sur la classe /LRN/CL_S4D401_ATS_CHECKED pour ouvrir le menu contextuel.
Dans le menu contextuel, sélectionnez Dupliquer....
Saisissez le nom de votre package dans la zone Package. Dans la zone Nom, saisissez le nom ZCL_##_SOLUTION, où ## représente votre numéro de groupe.
Cliquez sur Next.
Confirmez l'ordre de transport et cliquez sur Terminer.
Activez la copie.
Appuyez sur Ctrl + F3 pour activer la classe.
Tâche 2: Définir classe de test locale
Dans votre classe globale, définissez une classe de test locale (nom proposé : ltcl_find_flights). Définissez et implémentez un test pour la méthode find_cargo_flight de la classe lcl_Carrier.
Étapes
Créez une classe de test locale ltcl_find_flights.
Naviguez vers l'onglet Classes de test (inexistantes).
Si un bouton Créer classes de test... est affiché dans l'onglet, sélectionnez-le.
Placez le curseur à la fin du commentaire dans la première ligne de code source et appuyez sur Entrée.
Dans la nouvelle ligne de code source, saisissez test et appuyez sur Ctrl + Espace pour appeler la saisie semi-automatique du code source.
Sélectionnez le modèle de code source testClass - Test class (ABAP Unit) et appuyez sur Entrée.
Alors que le nom de classe préliminaire ltcl_ est mis en surbrillance, saisissez le nom de classe complet ltcl_find_flights.
Utilisez un correctif rapide pour renommer la méthode de test prédéfinie (nom suggéré : test_find_cargo_flight).
Cliquez avec le bouton droit de la souris sur first_test et sélectionnez Correctif rapide. Dans la liste qui s'affiche, sélectionnez Renommer premier_test. Pendant que le nom est mis en surbrillance, saisissez le nouveau nom test_find_cargo_flight.
Implémentez la méthode test_find_cargo_flight. Lisez les zones clés (carrier_id, connection_id, flight_date) et les deux aéroports (airport_from_id et airport_to_id) de tout vol cargo d'une capacité libre d'au moins 1 kg dans la table de base de données /LRN/CARGOFLIGHT. Stockez le résultat dans un objet de données approprié (nom suggéré : Some_flight_data).
Astuce
La capacité libre est calculée comme différence entre les deux zones de table maximum_load et actual_load.
Adaptez le code comme suit :
12345678910
METHOD test_find_cargo_flight.
SELECT SINGLE
FROM /lrn/cargoflight
FIELDS carrier_id, connection_id, flight_date,
airport_from_id, airport_to_id
WHERE maximum_load - actual_load >= 1
INTO @DATA(some_flight_data).
ENDMETHOD.
Si aucun ensemble de données approprié n'existe dans la table /LRN/CARGOFLIGHT, signalez le test comme ayant échoué.
Adaptez le code comme suit :
1234567891011121314
METHOD test_find_cargo_flight.
SELECT SINGLE
FROM /lrn/cargoflight
FIELDS carrier_id, connection_id, flight_date,
airport_from_id, airport_to_id
WHERE maximum_load - actual_load >= 1
INTO @DATA(some_flight_data).
IF sy-subrc <> 0.
cl_abap_unit_assert=>fail( `No suitable data in table /LRN/CARGOFLIGHT` ).
ENDIF.
ENDMETHOD.
Si vous avez pu lire un enregistrement approprié de la table /LRN/CARGOFLIGHT, utilisez la valeur carrier_id de cet enregistrement pour créer une instance de la classe lcl_Carrier (nom proposé pour la référence : the_Carrier).
Ajoutez le code suivant à la fin de la méthode :
12
DATA(the_carrier) = NEW lcl_carrier( i_carrier_id =
some_flight_data-carrier_id ).
Si le constructeur de la classe lcl_Carrier déclenche un rapport d'exception, le test a échoué.
Adaptez le code comme suit :
123456
TRY.
DATA(the_carrier) = NEW lcl_carrier( i_carrier_id =
some_flight_data-carrier_id ).
CATCH cx_abap_invalid_value.
cl_abap_unit_assert=>fail( `Unable to instantiate lcl_carrier` ).
ENDTRY.
Si l'instanciation est correcte, appelez la méthode find_cargo_flight pour l'instance de lcl_Carrier. Utilisez comme entrée les aéroports et la date du vol du fret sélectionné. Définissez la cargaison gratuite minimale (paramètre i_cargo) sur 1. Enregistrez le résultat dans des objets de données appropriés (noms suggérés : flight et days_later).
Ajoutez le code suivant à la fin de la méthode :
12345678910
the_carrier->find_cargo_flight(
EXPORTING
i_airport_from_id = some_flight_data-airport_from_id
i_airport_to_id = some_flight_data-airport_to_id
i_from_date = some_flight_data-flight_date
i_cargo = 1
IMPORTING
e_flight = data(flight)
e_days_later = data(days_later)
).
Analysez l'édition de la méthode. Appelez les méthodes assert appropriées pour vous assurer que le paramètre e_flight renvoie une référence d'objet valide et que le paramètre e_days_later renvoie zéro.
Remarque
Le fait que le paramètre e_days_later retourne la valeur zéro signifie que la méthode a trouvé un vol approprié directement le jour demandé. C'est ce que nous attendons si nous utilisons les propriétés d'un vol existant comme entrée.
À la fin de la méthode, ajoutez le code suivant :
12345678910
cl_abap_unit_assert=>assert_bound(
act = flight
msg = `Method find_cargo_flight does not return a result`
).
cl_abap_unit_assert=>assert_equals(
act = days_later
exp = 0
msg = `Method find_cargo_flight returns wrong result`
).
Activez votre classe.
Appuyez sur Ctrl + F3 pour activer la classe.
Tâche 3: Exécution du test unitaire
Exécutez le test unitaire. Analysez le résultat et ajustez l'implémentation de la méthode find_cargo_flight si le test retourne une erreur.
Attention
Si le test de module est interrompu avec le message Durée maximale autorisée de 60 secondes dépassée, augmentez le temps d'exécution attendu. Pour ce faire, modifiez l'option DURATION dans l'instruction CLASS … DEFINITION de votre classe de test de DURATION SHORT à DURATION MEDIUM.
Étapes
Exécutez les tests de module dans votre classe globale ZCL_##_SOLUTION.
Dans l'explorateur de projets, cliquez avec le bouton droit de la souris sur la classe ZCL_##_SOLUTION et sélectionnez Exécuter en tant que→test unitaire ABAP.
Lorsque le test est terminé, analysez le résultat dans la vue ABAP Unit.
S'il n'est pas déjà affiché, cliquez sur l'onglet ABAP Unit dans la section inférieure de l'écran.
Vous devez voir la valeur 1 en regard de l'icône Échecs/Erreurs.
Dans l'arborescence, sélectionnez le nom de la méthode de test ( zcl_##_solution→ltcl_find_flights→test_find_cargo_flight ) pour afficher les détails de l'erreur.
Analysez le code de la méthode find_cargo_flight et corrigez l'erreur.
Dans l'arborescence, double-cliquez sur test_find_cargo_flight pour accéder à l'implémentation de la méthode de test.
Faites défiler vers le bas jusqu'à l'appel de la méthode find_cargo_flight. Positionnez le curseur sur le nom de la méthode et appuyez sur F3 pour accéder à son implémentation.
Recherchez le calcul de days_later. Ici, la date du vol est soustraite de la date fournie. Ce devrait être l'inverse.
Pour corriger l'erreur, ajoutez un signe de commentaire devant cette instruction :
Et remplacez-le par ce code :
1
DATA(days_later) = flight->flight_date - i_from_date.
Activez votre classe et exécutez à nouveau le test unitaire pour confirmer que l'erreur a disparu.
Appuyez sur Ctrl + F3 pour activer la classe.
Sélectionnez Réexécuter tests dans la barre d'outils de l'onglet ABAP Unit.
Assurez-vous que le test affiche maintenant aucun échec/aucune erreur.
Exécutez votre classe globale comme application console pour vous assurer que la date du prochain vol de fret disponible est raisonnablement proche dans le futur.
Tâche 4: Implémentez la méthode CLASS_SETUP (facultatif).
Vous prévoyez d'ajouter d'autres méthodes de test à votre classe de test qui auront toutes besoin d'une instance de lcl_Carrier. Pour améliorer la performance de vos tests, déplacez l'instanciation chronophage de la classe lcl_Carrier vers la méthode class_setup car cette méthode n'est exécutée qu'une seule fois pour tous les tests de la classe de test.
Étapes
Définissez une méthode statique privée class_setup (sans paramètres) dans votre classe de test ltcl_find_flights et utilisez un quickfix pour ajouter l'implémentation de méthode.
Ajoutez le code suivant à la section privée de la classe ltcl_find_flights.
1
CLASS-METHODS class_setup.
Cliquez avec le bouton droit de la souris sur class_setup et sélectionnez Quick Fix.
Dans la liste de propositions, sélectionnez Ajouter implémentation pour class_setup.
Dans la classe de test, déclarez un attribut statique privé dans lequel vous pouvez stocker une référence à une instance de la classe lcl_Carrier (nom suggéré : the_Carrier).
Ajoutez le code suivant à la section privée de la classe ltcl_find_flights.
1
CLASS-DATA the_carrier TYPE REF TO lcl_carrier.
Déclarez un attribut statique privé dans lequel vous pouvez stocker un enregistrement de la table de base de données /LRN/CARGOFLIGHT (nom suggéré : Some_flight_data).
Ajoutez le code suivant à la section privée de la classe ltcl_find_flights.
1
CLASS-DATA some_flight_data TYPE /lrn/cargoflight.
Déplacez l'instruction SELECT et l'instanciation de la classe lcl_Carrier de la méthode test_find_cargo_flight vers la méthode class_setup. Stockez les données de la base de données dans l'attribut statique Some_flight_data et la référence à l'instance de lcl_Carrier dans l'attribut statique the_Carrier.
Coupez le code suivant de l'implémentation de la méthode test_find_cargo_flight et collez-le dans l'implémentation de la méthode class_setup.
1234567891011121314151617
SELECT SINGLE
FROM /lrn/cargoflight
FIELDS carrier_id, connection_id, flight_date,
airport_from_id, airport_to_id
WHERE maximum_load - actual_load >= 1
INTO @DATA(some_flight_data).
IF sy-subrc <> 0.
cl_abap_unit_assert=>fail( `No suitable data in table /LRN/CARGOFLIGHT` ).
ENDIF.
TRY.
DATA(the_carrier) = NEW lcl_carrier( i_carrier_id =
some_flight_data-carrier_id ).
CATCH cx_abap_invalid_value.
cl_abap_unit_assert=>fail( `Unable to instantiate lcl_carrier` ).
ENDTRY.
Remplacez INTO @DATA(some_flight_data) par INTO CORRESPONDING FIELDS OF @some_flight_data.
Remplacez DATA(the_carrier) par the_carrier.
Maintenant, le code de la méthode class_setup doit ressembler à ceci :
123456789101112131415161718192021
METHOD class_setup.
SELECT SINGLE
FROM /lrn/cargoflight
FIELDS carrier_id, connection_id, flight_date,
airport_from_id, airport_to_id
WHERE maximum_load - actual_load >= 1
INTO CORRESPONDING FIELDS OF @some_flight_data.
IF sy-subrc <> 0.
cl_abap_unit_assert=>fail( `No suitable data in table /LRN/CARGOFLIGHT` ).
ENDIF.
TRY.
the_carrier = NEW lcl_carrier( i_carrier_id =
some_flight_data-carrier_id ).
CATCH cx_abap_invalid_value.
cl_abap_unit_assert=>fail( `Unable to instantiate lcl_carrier` ).
ENDTRY.
ENDMETHOD.
Activez la classe et exécutez à nouveau le test de module pour vous assurer qu'il fonctionne toujours.
Appuyez sur Ctrl + F3 pour activer la classe.
Exécutez le test unitaire comme avant.
