After some consideration here is my solution to the problem. It works based on the assumption that development environment propath is different from test and production environments and code is always re-compiled for test or production use:
The code is designed to avoid any side effects and works equally well in any execution environment (GUI or ChUI, WebSpeed, AppServer, batch and so on).
1) Save the code as a file called “assert” (without any extension).
2) Place the file into a directory pointed to by PROPATH.
3) Sample usage:
{assert valid-handle(hProc)}
{assert i > 0 and i <= 100}
{assert cExtra begins ‘opt’} /* note the single quotes */
{assert dtEnd > = dtStart}
As a variation it’s possible to avoid relying on propath altogether by having just an empty include file in test and production environment, the development version will become just:
MESSAGE THIS-PROCEDURE:FILENAME "ERROR...{&CONDITION}"
VIEW-AS ALERT-BOX.
/* add code to email message etc.. or stop */
结束。
&ENDIF
/* debugalert.i 在测试或开发环境中
要关闭断言，请删除此语句 */
&GLOBAL-DEFINE DEBUGALERT
/* 在您的测试代码中，您只需执行以下操作：/
/ 测试断言 */
DEF VAR h_ct AS INT NO-UNDO INIT 10.
{assert.i &CONDITION="h_ct = 8"}
Given that assertions are generally omitted from the final code I'd suggest the preprocessor route. You might do something like the following set it up as two include files. When you are compiling it to production ensure that the debugalert.i is empty. assert.i could be edited to do whatever you like message, stop, email etc...
To setup an assertion you would just follow the format {assert.i &condition=}
/* assert.i */
{debugalert.i}
&IF DEFINED( DEBUGALERT ) <> 0 &THEN
IF NOT {&CONDITION}
THEN DO:
MESSAGE THIS-PROCEDURE:FILENAME "ERROR...{&CONDITION}"
VIEW-AS ALERT-BOX.
/* add code to email message etc.. or stop */
END.
&ENDIF
/* debugalert.i on test or development environments
to turn off the assertions remove this statement */
&GLOBAL-DEFINE DEBUGALERT
/* In your test code you would just do the following: /
/ testing assertion */
发布评论
评论（4）
经过一番考虑，这是我对问题的解决方案。 它的工作原理基于以下假设：开发环境 propath 与测试和生产环境不同，并且代码始终重新编译以供测试或生产使用：
代码旨在避免任何副作用，并且在任何执行环境（GUI 或ChUI、WebSpeed、AppServer、批处理等）。
1）将代码保存为名为“assert”的文件（不带任何扩展名）。
2) 将文件放入PROPATH 指向的目录中。
3）示例用法：
作为一种变体，可以通过在测试和生产环境中仅使用一个空包含文件来完全避免依赖 propath，开发版本将变得只是：
一个额外的提示是向编辑器添加自动文本宏选择将自动扩展为 {assert }。
After some consideration here is my solution to the problem. It works based on the assumption that development environment propath is different from test and production environments and code is always re-compiled for test or production use:
The code is designed to avoid any side effects and works equally well in any execution environment (GUI or ChUI, WebSpeed, AppServer, batch and so on).
1) Save the code as a file called “assert” (without any extension).
2) Place the file into a directory pointed to by PROPATH.
3) Sample usage:
As a variation it’s possible to avoid relying on propath altogether by having just an empty include file in test and production environment, the development version will become just:
An extra tip is to add an auto-text macro to your editor of choice that will automatically expand into {assert }.
由于 Progress 没有对断言的本机处理，但我想出的最好方法是：
assertionFailed.p 可以向程序员发送电子邮件，或记录条件并优雅退出。
Since Progress doesn't have native handling for assertions, but best I've come up with is:
assertionFailed.p can email the programmer, or log the conditions and also exit gracefully.
鉴于最终代码中通常会省略断言，我建议使用预处理器路线。 您可以执行如下操作，将其设置为两个包含文件。 当您将其编译到生产环境时，请确保 debugalert.i 为空。 可以编辑assert.i来执行任何您喜欢的消息、停止、电子邮件等...
要设置断言，您只需遵循格式 {assert.i &condition=}
/* assert.i */
{debugalert.i}
&IF DEFINED(DEBUGALERT) <> 0 &THEN
IF NOT {&条件}
然后做：
结束。
&ENDIF
/* debugalert.i 在测试或开发环境中
要关闭断言，请删除此语句 */
&GLOBAL-DEFINE DEBUGALERT
/* 在您的测试代码中，您只需执行以下操作：/
/ 测试断言 */
DEF VAR h_ct AS INT NO-UNDO INIT 10.
{assert.i &CONDITION="h_ct = 8"}
Given that assertions are generally omitted from the final code I'd suggest the preprocessor route. You might do something like the following set it up as two include files. When you are compiling it to production ensure that the debugalert.i is empty. assert.i could be edited to do whatever you like message, stop, email etc...
To setup an assertion you would just follow the format {assert.i &condition=}
/* assert.i */
{debugalert.i}
&IF DEFINED( DEBUGALERT ) <> 0 &THEN
IF NOT {&CONDITION}
THEN DO:
END.
&ENDIF
/* debugalert.i on test or development environments
to turn off the assertions remove this statement */
&GLOBAL-DEFINE DEBUGALERT
/* In your test code you would just do the following: /
/ testing assertion */
DEF VAR h_ct AS INT NO-UNDO INIT 10.
{assert.i &CONDITION="h_ct = 8"}
OpenEdge 11.6 将单元测试引入了 ABL 世界。 它大致基于 JUnit 原则。 因此，断言现在是包的一部分。 更多信息位于文档中： https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pdsoe/overview-of-ablunit-testing-framework.html
OpenEdge 11.6 introduced Unit Testing to the world of ABL. It's loosely based on JUnit principals. Assertions are therefore now part of the package. More info is in the documentation: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pdsoe/overview-of-ablunit-testing-framework.html