Alex has not published any posts yet.

Suggest use "Return" keyword instead of "Quit"

For example:

Class Test.ReturnOfTheTry [ Abstract ]

  ClassMethod GetReturn(state = 0)
    try {
      if state=1 return "In Try"
      set x=3/0
    } catch {
      if state=2 return "In Catch"
  quit "At Methods End"


// Usage example

Write ##class(Test.ReturnOfTheTry).GetReturn(1)
In Try
Write ##class(Test.ReturnOfTheTry).GetReturn(2)
In Catch
Write ##class(Test.ReturnOfTheTry).GetReturn()
At Methods End

Hi Alberto,

I have an alternative approach that uses Class based Unit Tests for DTL.

Essentially it uses pairs of XDATA blocks to hold the input and expected output messages.

It automatically generates the UnitTest Compare by assertion implementation with assertions, by first analysing the existing DTL path expressions in your real DTLs. code.

The advantage for this is:

1) It doesn't require external folders to store input and output messages.

2) The test input and output message are source controlled with the unit-test class.

3) Easily ignore comparison of specific paths set in DTL that you don't want to compare. For example paths set to todays date or a numeric sequence would always be different so we can easily comment out these specific generated assertions. ie: Not compare the whole input and output file.

4) There is a utility method when given a class package it will seek out and find and generate DTL unit test classes with tailored "compare assertion" methods

5) There is Assertion for paths being found in the input document. For example: If you have a recent change to the schema, and your existing Tests appear to pass. ie: A target field is empty as expected. This unit test will still pick up that the source field is in accessible using the current schema.

6) The ordering of assertions in path loops is re-ordered to be more processing efficient.

7) Its using a more "Row Driven" unit test methodology. ie: An analyst can keep just adding the pairs of XDATA input and expected output messages to the same UnitTest class without the knowledge for how to implement unit-tests. I had considered providing a Studio template to facilitate this, or to pull sample messages into a DTL class where sample messages are available on the system in focus.

Limitations: It works for HL7-to-HL7 and HL7-to Objects. It needs further work for Object-to-Object to auto-generate to compare assertion method.

Note: I also have a classes based UnitTest base for stressing routing rules in an existing production along similar lines.

Let me know if interested. Maybe can share to community.

Kind regards,


Open Exchange applications:
Alex has no followers yet.
Alex has not followed anybody yet.
Global Masters badges:
Alex has no Global Masters badges yet.