Mise en œuvre des assertions en cours 4GL

Question

Quel est le meilleur moyen de mettre en œuvre les assertions à l'aide de Progress 4GL ou de WebSpeed?

Answer 1

Après mûre réflexion, voici ma solution au problème. Il fonctionne en partant du principe que l'environnement de développement est différent des environnements de test et de production et que le code est toujours recompilé pour un usage de test ou de production:

&IF PROPATH MATCHES '*development*' &THEN 
&SCOPED-DEFINE ASSERTION   {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} ~
{11} {12} {13} {14} {15} {16} {17} {18} {19} {20} ~
{21} {22} {23} {24} {25} {26} {27} {28} {29} {30} ~
{31} {32} {33} {34} {35} {36} {37} {38} {39} {40} ~
{41} {42} {43} {44} {45} {46} {47} {48} {49} {50} ~
{51} {52} {53} {54} {55} {56} {57} {58} {59} {60} ~
{61} {62} {63} {64} {65} {66} {67} {68} {69} {70} ~
{71} {72} {73} {74} {75} {76} {77} {78} {79} {80} 


 IF NOT ({&ASSERTION}) THEN 
     MESSAGE "Failed assertion {&ASSERTION} in" PROGRAM-NAME(1).

 IF ({&ASSERTION}) = ? THEN 
     MESSAGE "Unknown value as a result of assertion {&ASSERTION} in" 
              PROGRAM-NAME(1).

&ENDIF

Le code est conçu pour éviter tout effet secondaire et fonctionne aussi bien dans tout environnement d'exécution (interface graphique ou ChUI, WebSpeed, AppServer, batch, etc.).

1) Enregistrez le code dans un fichier nommé & # 8220; assert & # 8221; (sans aucune extension).

2) Placez le fichier dans un répertoire désigné par PROPATH.

3) Exemple d'utilisation:

{assert valid-handle(hProc)}
{assert i > 0 and i <= 100}
{assert cExtra begins ‘opt’}  /* note the single quotes */
{assert dtEnd > = dtStart}

En variante, & # 8217; il est possible d'éviter de se fier entièrement à propath en disposant simplement d'un fichier include vide dans les environnements de test et de production, la version de développement deviendra simplement:

&SCOPED-DEFINE ASSERTION   {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} ~
{11} {12} {13} {14} {15} {16} {17} {18} {19} {20} ~
{21} {22} {23} {24} {25} {26} {27} {28} {29} {30} ~
{31} {32} {33} {34} {35} {36} {37} {38} {39} {40} ~
{41} {42} {43} {44} {45} {46} {47} {48} {49} {50} ~
{51} {52} {53} {54} {55} {56} {57} {58} {59} {60} ~
{61} {62} {63} {64} {65} {66} {67} {68} {69} {70} ~
{71} {72} {73} {74} {75} {76} {77} {78} {79} {80} 


 IF NOT ({&ASSERTION}) THEN 
     MESSAGE "Failed assertion {&ASSERTION} in" PROGRAM-NAME(1).

 IF ({&ASSERTION}) = ? THEN 
     MESSAGE "Unknown value as a result of assertion {&ASSERTION} in" 
              PROGRAM-NAME(1).

Une astuce supplémentaire consiste à ajouter une macro à texte automatique à l'éditeur de votre choix, qui se développera automatiquement en {assert}.

Answer 2

Puisque Progress n’a pas de gestion native des assertions, le mieux que j’ai proposé est:

IF NOT <assertion> THEN
RUN assertionFailed.p.

assertionFailed.p peut envoyer un courrier électronique au programmeur, ou enregistrer les conditions et également quitter normalement.

Answer 3

Étant donné que les assertions sont généralement omises du code final, je suggérerais la route du préprocesseur. Vous pouvez faire quelque chose comme ce qui suit, configurez-le en deux fichiers d'inclusion. Lorsque vous le compilez en production, assurez-vous que le fichier debugalert.i est vide. assert.i peut être édité pour faire ce que vous voulez comme message, stop, email, etc ...

Pour configurer une assertion, il vous suffit de suivre le format {assert.i & amp; condition =}

/ * assert.i * / {debugalert.i}

& et IF DEFINED (DEBUGALERT) < > 0 & Amp; THEN

SI PAS {& amp; CONDITION} ALORS FAIRE:

MESSAGE THIS-PROCEDURE:FILENAME "ERROR...{&CONDITION}" 
    VIEW-AS ALERT-BOX.
/* add code to email message etc.. or stop */

FIN.

& amp; ENDIF

/ * debugalert.i sur les environnements de test ou de développement    pour désactiver les assertions, supprimez cette déclaration * /

& GLOBAL-DEFINE DEBUGALERT

/ * Dans votre code de test, procédez comme suit: / / test de l'assertion * /

DEF VAR h_ct AS INT NO-UNDO INIT 10.

{assert.i & amp; CONDITION = " h_ct = 8 "}}

Answer 4

OpenEdge 11.6 a introduit le test unitaire dans le monde ABL. C'est vaguement basé sur les principes de JUnit. Les assertions font donc maintenant partie du paquet. Plus d'informations dans la documentation: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pdsoe/overview-of-ablun-testing-framework.html