Open EvanMachusak opened 2 months ago
Throughout the spec, specifically the Arithmetic tests, we have cases that are testing coercion of data types instead of the actual operation itself. For example:
<test name="Floor1"> <expression>Floor(1)</expression> <output>1</output> </test>
This test has no specific value to the Floor operator, which is defined this way:
Floor
Floor(argument Decimal) Integer
If we want to test type coercion, we should be doing so in a library that is purpose built, e.g.
define function "Takes decimal"(i System.Decimal): 42 define "Test": "Takes decimal"(1)
With an expectation that "Test" equals 42.
"Test"
42
There are dozens of tests that are not materially different than other tests except that they coerce an integer to a decimal, e.g.:
<test name="Divide11"> <expression>1 / 1</expression> <output>1.0</output> </test> <test name="Divide1d1d"> <expression>1.0 / 1.0</expression> <output>1.0</output> </test>
We should eliminate Divide11 and preserve only Divide1d1d. The signature of Divide is:
Divide11
Divide1d1d
Divide
/(left Decimal, right Decimal) Decimal /(left Quantity, right Quantity) Quantity
There is no integer overload. We should not be testing one.
Throughout the spec, specifically the Arithmetic tests, we have cases that are testing coercion of data types instead of the actual operation itself. For example:
This test has no specific value to the
Floor
operator, which is defined this way:Floor(argument Decimal) Integer
If we want to test type coercion, we should be doing so in a library that is purpose built, e.g.
With an expectation that
"Test"
equals42
.There are dozens of tests that are not materially different than other tests except that they coerce an integer to a decimal, e.g.:
We should eliminate
Divide11
and preserve onlyDivide1d1d
. The signature ofDivide
is:There is no integer overload. We should not be testing one.