In unit testing assertions are used to confirm desired properties of the
result, not of the input.
Checking desired properties of the input is called validation. Validation
can be performed in many ways, including "catch-all" templates.
Validations and assertions may seem similar, but they have different goals.
Assertions aren't even executed if the input validation fails.
Thanks,
Dimitre
On Fri, Apr 29, 2022 at 6:56 AM Roger L Costello costello(_at_)mitre(_dot_)org <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi Folks,
I'd like to get your thoughts on how to effectively use assertions in the
following use case.
Use Case: I am mapping a military air navigation standard to a civilian
air navigation standard. I have determined that this military element:
<xs:element name="TYPE">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="A" />
<xs:enumeration value="B" />
<xs:enumeration value="C" />
<xs:enumeration value="D" />
</xs:restriction>
</xs:simpleType>
</xs:element>
is the best match for this civilian element:
<xs:element name="publicMilitaryIndicator">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Civil" />
<xs:enumeration value="Joint" />
<xs:enumeration value="Military" />
<xs:enumeration value="Private" />
</xs:restriction>
</xs:simpleType>
</xs:element>
The mapping is as follows:
A maps to Civil.
B maps to Joint.
C maps to Military.
D has a different meaning than Private so whenever D is encountered an
error should be generated.
I created a bunch of template rules for generating an instance of the
civilian standard. Each template rule generates one civilian element. Below
is the template rule for generating the publicMilitaryIndicator element.
The template rule is passed (via xsl:param) a row (ARPT_row) from the
military standard. In APRT_row is a child element, TYPE. The template rule
maps TYPE to publicMilitaryIndicator.
<xsl:template match="airport/publicMilitaryIndicator">
<xsl:param name="ARPT_row" as="element(row)"/>
<publicMilitaryIndicator>
<xsl:variable name="ind" select="$ARPT_row/TYPE"/>
<xsl:choose>
<xsl:when test="$ind eq 'A'">Civil</xsl:when>
<xsl:when test="$ind eq 'B'">Joint</xsl:when>
<xsl:when test="$ind eq 'C'">Military</xsl:when>
<xsl:when test="$ind eq 'D'">**error**</xsl:when>
<xsl:otherwise>
<xsl:value-of select="'Invalid TYPE'"/>
</xsl:otherwise>
</xsl:choose>
</publicMilitaryIndicator>
</xsl:template>
I eyeball that code and swear it's correct. Alas, my eyeballs often
deceive me. I'd like a greater level of assurance that the code is correct.
I'd like to add assertions to the code to raise the level of assurance. But
what assertions would be useful in this code? Would it be useful to add an
assertion that ARPT_row has a TYPE child element? And another assertion
that the value of TYPE is not empty?
<xsl:template match="airport/publicMilitaryIndicator">
<xsl:param name="ARPT_row" as="element(row)"/>
<xsl:assert test="exists($ARPT_row/TYPE)" /> <-- IS THIS USEFUL?
<xsl:assert test="$ARPT_row/TYPE ne ''" /> <-- IS THIS USEFUL?
<publicMilitaryIndicator>
<xsl:variable name="ind" select="$ARPT_row/TYPE"/>
<xsl:choose>
<xsl:when test="$ind eq 'A'">Civil</xsl:when>
<xsl:when test="$ind eq 'B'">Joint</xsl:when>
<xsl:when test="$ind eq 'C'">Military</xsl:when>
<xsl:when test="$ind eq 'D'">**error**</xsl:when>
<xsl:otherwise>
<xsl:value-of select="'Invalid TYPE'"/>
</xsl:otherwise>
</xsl:choose>
</publicMilitaryIndicator>
</xsl:template>
Are those assertions useful? Are there other assertions that would be
useful?
I have read that it is good to identify relations that should hold true
throughout the code, i.e., invariants. It would be wicked cool if I could
identify an invariant for this mapping problem. But I have no idea what
invariant there is with this mapping problem. Any thoughts on what
invariant there is in this mapping problem?
I can see how programs involving mathematics can have an invariant, i.e.,
some mathematical relation must be true throughout the code's
manipulations. Are there invariants in non-mathematical problems?
/Roger
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--