将 DUnit CheckEquals 中的问题与货币字段值进行比较

Question

我正在比较 DUnit 中的一些货币值，但它在我的机器上根本不起作用（在其他机器上起作用，但在我的机器上不起作用）。

示例：

CheckEquals(16.65, SomeCurrencyFieldValue);

Raises：

expected: <16,65> but was: <16,65>

如果执行以下操作，则比较有效：

var
  Temp: Currency;
begin
  Temp := 16.65;
  CheckEquals(Temp, SomeCurrencyFieldValue);

问题是：为什么当我将值直接传递给 CheckEquals 方法时比较不起作用？

Answer 1

该问题与运行时的货币值如何转换为扩展值以及浮点文字如何在运行时转换为扩展值有关。编译时间。 如果两种情况下的转换不同，则传递给 CheckEquals 的值可能不相等。

值得在调试器的 CPU 窗口中检查其中任何一个值在为函数调用做准备的过程中是否经过中间 Double 值到 Extended 。 额外的转换会影响结果的确切值。

另一件需要考虑的事情是，16.65 不能精确地表示为扩展值，但它可以精确地表示为货币值。 尽管 Currency 被归类为浮点类型，但它实际上是定点缩放的 64 位整数。 这可能是在考虑到这一点的 DUnit 中请求额外的 CheckEquals 重载的理由。

Answer 2

我看到 Delphi 2007 dUnit 源代码中只有 CheckEquals() 用于扩展值。 但您可以使用这个：

procedure CheckEquals(expected, actual: extended; delta: extended;
  msg: string = ''); overload; virtual;

并为货币价值提供适当的增量。

Answer 3

我遇到了同样的问题。 看起来有些 DLL 会修改 FPU（处理器）控制字。 这解释了为什么错误并不总是发生。 当添加一些使用先前测试套件以外的单元的新测试时，它可能会突然出现。 或者软件更新安装了错误的 DLL。 我在我的博客上写过：

• 为什么 1.99 突然不再等于1.99

我还发现Delphi包含一个SafeLoadLibrary函数，它可以恢复控制字。

这也解释了为什么原来的问题提到问题是机器相关的。

Answer 4

这是一个建议的解决方案：

procedure CheckEquals(expected, actual: double; Precision:integer; msg:string ='');overload;virtual;

...

procedure TAbstractTest.CheckEquals(expected, actual: double;
  Precision: integer; msg: string);
var
  I: Integer;
begin
  FCheckCalled := true;
  for I := 0 to Precision do begin
    Expected := Expected * 10;
    Actual := Actual * 10;
  end;
  if Round(Expected) <> Round(Actual) then
    FailNotEquals( IntToStr(Round(Expected)), IntToStr(Round(Actual)), msg, CallerAddr);
end;

我知道它的实现很糟糕，但这只是一个想法，我比“delta”更喜欢它，而且更容易使用。

在当前版本的 dunit 中，您可以使用

procedure CheckEquals(expected, actual: extended; delta: extended; msg: string = ''); overload; virtual;
CheckEquals(0.011,0.01,0.009,'will pass');