Instruction ABAP ASSERT expliquee : Assertions pour les tests et le debogage

L’instruction ASSERT sert a faire des assertions sur l’etat de votre programme au moment de l’execution et a les verifier. Une assertion est une condition dont vous, en tant que developpeur, etes convaincu qu’elle doit toujours etre vraie (abap_true) a un endroit specifique du code.

ASSERT est principalement un outil pour :

• Le developpement et les tests : Pour detecter precocement les erreurs logiques dans le programme ou les hypotheses incorrectes sur les etats des donnees.
• Le debogage : Pour determiner rapidement a quel endroit une hypothese a ete violee.
• La documentation du code : Pour consigner explicitement les hypotheses sur l’etat du programme dans le code.

Distinction importante : ASSERT n’est pas destine a la gestion normale des erreurs (par ex. entrees utilisateur invalides, etats d’erreur attendus dans la logique metier) dans les environnements de production. Pour cela, vous devez utiliser des requetes IF, MESSAGE, RAISE EXCEPTION, etc. ASSERT verifie les erreurs de programmation ou les etats qui ne devraient “jamais” se produire.

Syntaxe

ASSERT [ ID <groupe_assertion> ]
       [ SUBKEY <sous_cle> ]
       [ FIELDS <champ1> <champ2> ... ]
       CONDITION <expression_logique>. " Le mot-cle CONDITION est obligatoire !

• ID <groupe_assertion> (Optionnel) : Attribue l’assertion a un “groupe de checkpoint” ou “groupe d’assertion”. Ces groupes peuvent etre actives, desactives ou configures de maniere centralisee (transaction SAAB). C’est tres utile pour controler le comportement des assertions a l’echelle du systeme ou specifique a l’utilisateur.
• SUBKEY <sous_cle> (Optionnel) : Un texte supplementaire (sous-cle) pour une identification ou une contextualisation plus poussee de l’assertion au sein d’un groupe ID.
• FIELDS <champ1> <champ2> ... (Optionnel) : Ici, vous pouvez specifier une liste d’objets de donnees (variables). Si l’assertion echoue, les valeurs de ces champs seront affichees dans le protocole (log) ou dans le dump court, ce qui facilite considerablement la recherche d’erreurs.
• CONDITION <expression_logique> : Obligatoire ! C’est l’expression logique qui est evaluee. L’assertion est consideree comme remplie (reussie) si cette expression est evaluee a abap_true.

Fonctionnement et comportement en cas d’echec

Au moment de l’execution, l’<expression_logique> est verifiee :

1. Si la condition est abap_true (vraie) : L’assertion est remplie. Rien d’autre ne se passe, et le programme continue normalement. Votre hypothese sur l’etat du programme etait correcte.
2. Si la condition est abap_false (fausse) : L’assertion echoue. Ce qui se passe ensuite depend du parametre d’activation de l’assertion (controle via l’ID, SUBKEY dans la transaction SAAB ou les parametres systeme globaux) :
   • Inactif : L’instruction ASSERT est completement ignoree. Elle n’a aucun effet sur l’execution ou les performances. C’est le parametre par defaut pour les systemes de production.
   • Actif - Mode ‘Log’ : L’echec de l’assertion est journalise (par ex. dans le log systeme, transaction SM21, ou dans un log special pour les groupes de checkpoint). Les valeurs specifiees sous FIELDS peuvent etre enregistrees. Le programme continue ensuite. Ce mode est utile dans les systemes de test ou d’assurance qualite.
   • Actif - Mode ‘Abort’/‘Break’ : Le programme s’arrete avec une erreur d’execution (dump court) du type ASSERTION_FAILED, ou il s’arrete dans le debogueur a cet endroit (selon le parametre). C’est souvent le parametre souhaite pendant la phase de developpement, pour etre immediatement alerte de l’erreur logique.

Cas d’utilisation

• Verification des preconditions pour les methodes ou les modules fonctionnels (par ex. ASSERT CONDITION parameter IS NOT INITIAL.).
• Verification des postconditions apres l’execution de blocs de code (par ex. ASSERT CONDITION resultat > 0.).
• Verification des invariants (etats qui devraient toujours etre valides, par ex. dans une boucle ou pour un objet, ASSERT CONDITION object_ref IS BOUND.).
• Protection contre les etats “impossibles” dans les structures CASE ou IF (par ex. dans la branche WHEN OTHERS d’une instruction CASE, ou aucun autre cas n’est attendu : ASSERT CONDITION 1 = 0.).

Exemples

1. Verification simple de precondition

METHOD calculate_price.
  IMPORTING quantity TYPE i.

  " Hypothese : La quantite ne doit pas etre negative pour ce calcul
  ASSERT CONDITION quantity >= 0.

  " ... Calcul du prix ...
ENDMETHOD.

2. Verification de postcondition avec FIELDS

DATA total TYPE p DECIMALS 2.
DATA item_count TYPE i.

" ... Code qui calcule total et item_count ...

ASSERT ID zmy_calc_group SUBKEY 'FinalCheck"
       FIELDS total item_count
       CONDITION total >= 0 AND ( item_count = 0 OR total > 0 ).
" Hypothese : Total jamais negatif ; s'il y a des articles, la somme doit etre > 0.

3. Verification d’une reference objet

DATA factory TYPE REF TO zcl_my_factory.
DATA instance TYPE REF TO zif_my_interface.

factory = zcl_my_factory=>get_instance( ).
ASSERT CONDITION factory IS BOUND. " Hypothese : La factory existe toujours

instance = factory->create_object( type = 'A' ).
ASSERT CONDITION instance IS BOUND. " Hypothese : L'objet a ete cree avec succes

instance->do_work( ).

Remarques importantes / Bonnes pratiques

• Utilisez ASSERT comme outil d’assurance qualite pendant le developpement et les tests, pas pour traiter les erreurs d’execution attendues dans le systeme de production.
• Utilisez toujours l’ajout ID pour rendre vos assertions controlables via SAAB. Choisissez des noms de groupe pertinents.
• Utilisez l’ajout FIELDS pour voir les valeurs des variables pertinentes en cas d’erreur.
• Assurez-vous que les assertions sont inactives par defaut dans les systemes de production pour eviter les pertes de performance ou les arrets indesirables. L’activation se fait ensuite de maniere ciblee en cas de besoin pour l’analyse.
• Ecrivez des assertions pour toutes les hypotheses non triviales que vous faites sur votre code ou vos donnees.