Test-Driven Development with Dexterity

Often, when speaking to Visual Studio developers I am introduced to some new (or not so new) software engineering technique available via the slur of tools provided by Team Foundation Server (TFS). One of such tools is the ability to write/implement in-line test cases along with the rest of your code. This is known in Software Engineering as Test-Driven development or is sometimes referred to as self-testing code.

Dexterity also has these capabilities, believe it or not. Sufficient to say, that the Dexterity development environment and the sanScript language were conceived by Software Engineering and Compiler purists who were way ahead of their time back in the 80s when the mid market ERP was racing towards identifying a clear leader -- see Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

To address this issue, the SanScript language implements assertions. See A Historical Perspective on Runtime Assertion Checking in Software Engineering. An assertion is a claim about the state of computation at the time the assertion is evaluated. Assertions are always written as statements the programmer believes to be true. You can make your code self-testing by adding assertions at different stages. When the assertion fails there may be a potential problem with the script you are writing.

In Dexterity, the assert statement is primarily used to implement these claims. When an assert statement is found, the Dex compiler will evaluate the boolean condition associated with the statement. If the condition turns out to be false, the compiler will display a message related to the assertion. As such, the assert statement is implemented as follows:


assert boolean_expression {, message}

The following code illustrates the implementation of an assertion:



In this case, our assertion or primary assumption is that the selling price of the item be greater than the item cost itself. If we attempt to execute this code with the values shown on the image, the following error will be produced.




Note that an assertion will not prevent the values entered from being saved, but Dexterity will provide the option of aborting the script execution, ignoring the assertion, or debugging the current code to examine other alternatives. For the example above, the developer can choose to implement additional code that will prevent the saving of a record if indeed the selling price must be always greater than the item cost.

The assert statement should be seen as a development and testing tool. The dialog box indicating an assertion failed should not be displayed to the users of your application. By default, the runtime engine will not display the dialog box, even though an assertion failed. To allow testing with the runtime engine, add the RuntimeAsserts=TRUE setting to the defaults file, DEX.INI. This forces the runtime engine to display the dialog box for any assertions that fail.

Since assertion dialogs should not be seen by users, and some overhead is involved in evaluating them, it is strongly recommended that you don’t compile assert statements for the final version of your product. To prevent assert statements from being compiled, don’t compile your application with debug information.



These compilation options can be found in Dexterity Utilities.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/