It's currently harder than it should be to interpret the test results in the DMN TCK.
The following expected test result
<expected>
<component name="a">
<value xsi:type="xsd:decimal">2</value>
</component>
</expected>
...maps to a FEEL context data structure with one entry:
{ a: 2 }
Adding another entry, the result looks like this:
<expected>
<component name="a">
<value xsi:type="xsd:decimal">2</value>
</component>
<component name="b">
<value xsi:type="xsd:decimal">2</value>
</component>
</expected>
The required FEEL data structure is a context again, containing two entries with a
and b
as keys:
{ a: 2, b: 2 }
Two issues make it hard to understand such test results:
- Context boundaries are not spawned explicitly
- Result names are not aligned with feel naming
Describe context explicitly using FEEL terminology:
<expected>
<context>
<entry name="a">
<value xsi:type="xsd:decimal">2</value>
</entry>
</context>
</expected>
Embedded into a list:
<expected>
<list>
<item>
<context>
<entry name="a">
<value xsi:type="xsd:decimal">2</value>
</entry>
</context>
</item>
</list>
</expected>
With multiple entries and context nesting:
<expected>
<context>
<entry name="a">
<value xsi:type="xsd:decimal">2</value>
</entry>
<entry name="b">
<context>
<entry name="foo">
<value xsi:type="xsd:string">BAR</value>
</entry>
</context>
</entry>
</context>
</expected>
A partial alternative for FEEL tests is to make these available standalone:
for item in [1, 2, 3][> 2] return concat("item-", string(item)) = [ "item-3" ]
1 + 6 * 3 = 19
For each of these entries, for a FEEL interpreter to pass the test:
engine.evalutateExpression(expression) === true