ruby-on-rails - rspec 大十进制匹配器

Question

-:total_cost_with_tax => #<BigDecimal:7fda9d17aaf0,'0.105225E4',18(45)>,
-:total_cost_without_tax => #<BigDecimal:7fda9d17b450,'0.972E3',9(36)>,
-:total_last_installment_amount => #<BigDecimal:7fda9d17b978,'0.8011E2',18(45)>,
-:total_monthly_installment_amount => #<BigDecimal:7fda9d17abb8,'0.8011E2',18(45)>,
-:total_tax => #<BigDecimal:7fda9d17b068,'0.8025E2',18(45)>,

+:total_cost_with_tax => #<BigDecimal:7fda9d0184c8,'0.105225E4',18(36)>,
+:total_cost_without_tax => #<BigDecimal:7fda91ff2b48,'0.972E3',9(27)>,
+:total_last_installment_amount => #<BigDecimal:7fda91fee548,'0.8011E2',18(36)>,
+:total_monthly_installment_amount => #<BigDecimal:7fda91fe72c0,'0.8011E2',18(36)>,
+:total_tax => #<BigDecimal:7fda9d00a2b0,'0.8025E2',18(36)>,

因此，这些在我的一些测试中随处可见……rspec 2，rails 3。我正在使用 .should eq() 比较哈希来进行比较。我似乎无法正确使用咒语。看起来这是一个精确的东西，这看起来很愚蠢。

Answer 1

RSpec 3 有 BigDecimal eq:

x.should eq(y)

expect(x).to eq(y)

如果您将 Bi​​gDecimal 与 Float 进行比较，请注意精度会影响比较。

你可以使用这个:

x.should be_within(delta).of(y)

expect x.to be_within(delta).of(y)

如果您比较两个具有不同精度的 BigDecimal 数字，请注意这些数字可能会显示来自 inspect 和 hash 的不同结果，具体取决于您的平台和您正在运行哪个版本的 Ruby BigDecimal。

例如，这可能发生:

BigDecimal.new("2").hash == BigDecimal.new("2.0").hash
=> false

您的输出显示您的 BigDecimal 字符串表示略有不同。

这是你的字符串的意思:

• 第1部分是对象地址。
• 第二部分是以字符串表示的数值。
• 第 3 部分是有效位数，然后是最大有效位数。

您的输出显示您的字符串具有不同的对象地址、相同的数值(即第 2 部分)、相同的有效数字(第 3 部分中的第一个数字)，但最大有效数字的数量不同。

对于您的问题，使用 RSpec 2 并比较 BigDecimal 哈希，您将通过使用 rspec be_within 匹配器解决您的问题。

请注意，Ruby BigDecimal 数字和 Float 数字都是 float :

• BigDecimal 是一个任意精度的十进制 float 。

• Float 是 native 架构的 double 二进制 float 。

通过这样做，您可以看到 BigDecimal 十进制浮点表示:

require 'bigdecimal'
x=BigDecimal.new(100)
=> #<BigDecimal:7f8e62038570,'0.1E3',9(27)>

尾数部分是'0.1'，指数部分是'E3'。

请注意，这是针对典型的 Ruby MRI/KRI VM 的。在其他 Ruby VM(例如 JRuby)上的实现可能有所不同，因为 Java 有自己的 bignum 代码。

当您比较两种不同类型的 float (例如 BigDecimal 和 Float)时，您会得到看似违反直觉的结果，因为这两种类型使用不同的基数(十进制与二进制)、不同的精度和不同的 Ruby类。

例子:

BigDecimal.new("1.111111111111111") === 1.111111111111111
=> true
BigDecimal.new("1.1111111111111111") === 1.1111111111111111
=> false