FitNesse Fixture plugin AssertRecord evaluates strings but not numerical value, thus returning false when values are equal as numbers. Attached patch solves it. (Patch includes trxName implementation for roll back. So if not implemented trxName thru-out, then discard trxName lines. RollBack will be submitted in next JIRA.)
Environment
None
Attachments
1
17 Sep 2015, 06:45 PM
Activity
RedhuanO
September 24, 2015 at 9:59 PM
There are usages such as @variable@ passed from @SQL statements that makes it more difficult to determine the usage of data type. Thus i think the more elegant solution is to introduce a new method exclusively to AssertNumbers. WDYT?
RedhuanO
September 21, 2015 at 11:41 PM
I see, yes I understand now. So can I check its source origin data type first? Thus if it is Amt or Qty based then right, otherwise wrong?
Carlos Ruiz
September 20, 2015 at 8:11 PM
Thanks , what concerns me about this patch is in the case you want to really compare two Strings, in the case both Strings contain valid numeric values the process will always assume they are numerically comparable. I mean, for example comparing M_Product.Value 1015 with another product with value 1015.0 - with this patch the comparison will be true - but Value is a String and it must be false.
FitNesse Fixture plugin AssertRecord evaluates strings but not numerical value, thus returning false when values are equal as numbers. Attached patch solves it.
(Patch includes trxName implementation for roll back. So if not implemented trxName thru-out, then discard trxName lines. RollBack will be submitted in next JIRA.)