Phpunit: assertEquals 在带有小数 ('0', '0.00') 的等效字符串上意外失败

当+符号在字符串中时，我也遇到了另一个（相关的？）问题，这正是我链接到的原始问题所说的应该_不_失败的问题。

$this->assertEquals('+1', '1');

Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'+1'
+'1'

我认为这可能是由于更改： https :

我做了更多调查，这对我来说在7.1.5上开始失败，这可能是由于该版本中sebastian/comparator的主要版本升级。 事实上，我现在猜测我看到的行为是由于https://github.com/sebastianbergmann/comparator/pull/58。

需要明确的是，我并不是说这一定是一个_坏_变化。 事实上，它可能在我之前通过测试的代码中发现了一些错误。 这只是补丁版本碰撞中的一个意外的突破性变化。

ping @Ocramius

@sebastianbergmann 根据我自己的知识，为了让每个人都清楚，断言的“预期”结果是什么
$this->assertEquals('+1', '1');和$this->assertEquals('0', '0.00'); ？

如果 php 根据==将它们视为相等，则assertEquals的合同是否应该通过断言？ 如果您想与===进行严格比较，请改用assertSame ？

不，它不是@IanVS ，
我的变化是针对 7.2。
7.1.4 带来了回归，7.1.3 有效

由于comparator包的变化，这两个例子都失败了，
作为一种解决方法，将"sebastian/comparator": "^2.1",到您的作曲家文件中，它将为您工作。

同时，我将深入研究比较器 3 问题

啊，在我打开页面，消失开会，回来输入我的答案之间 - 新的输入在这里。 刚看到：D

assertEquals 的契约是如果 php 根据 == 将它们视为相等，则断言应该通过？ 如果您想与 === 进行严格比较，请改用 assertSame？

确实，至少根据文档；）

这些是字符串：它们将作为字符串进行比较。 ==在类型不匹配时在内部使用。

@sebastianbergmann 根据我自己的知识，为了让每个人都清楚，断言的“预期”结果是什么
$this->assertEquals('+1', '1');和$this->assertEquals('0', '0.00'); ？

断言将失败。 您可以使用的正确断言是：

• $self::assertEquals(+1, '1');
• $self::assertEquals(+1, 1);
• $self::assertEquals(0, '0.00');
• $self::assertEquals('0', 0.00);

如果两者都是字符串，则类型杂耍只是危险的，因为您可能会将错误类型的数据从一层传递到下一层，而测试甚至无法捕获这些数据。

意外的重大变化

这是一个非常重要的错误修正。
是的，这意味着在糟糕的测试中可能存在 BC 中断，但我什至可以考虑将其升级为安全版本，因为您的测试失败并需要调整（请参阅 https://github.com/sebastianbergmann/phpunit/issues/3185# issuecomment-400578650）仍然比没有暴露一个潜伏的错误要好。

注意： self::assertEquals(new Comment('0.0'), new Comment('0.')) （是的，这是最好的例子——更多例子见 https://github.com/sebastianbergmann/comparator/pull/58/files）不能被self::assertSame(new Comment('0.0'), new Comment('0.'))替换。

是的，不是。 也许让我们介绍assertEqualsObjects需要传递 2 个相同类型的对象，并弃用assertEquals以阻止（后来禁止）依赖类型转换？

@sebastianbergmann ， IsEqual约束如何工作？
文档https://github.com/sebastianbergmann/phpunit/blob/master/src/Framework/Constraint/IsEqual.php#L19不是匹配的实现，我相信这带来了这个话题的混乱

ping @sebastianbergmann ，你能看看这个吗？

最终：是的。 这需要时间（思考和讨论）。

此问题已自动标记为过时，因为它在过去 60 天内没有活动。 如果没有进一步的活动，它将在 7 天后关闭。 感谢你的贡献。

你好，有没有进一步考虑这个？ （我主要是评论以保持问题的开放性，因为似乎没有解决方案。）

我们也受到这次严重的公元前中断的影响。 虽然我同意 #58 中的边缘情况很糟糕，应该避免，但我不认为更改assertEquals是正确的举动。 AssertEquals 一直是（对我来说），关于可能包括类型杂耍的松散比较。 如果您知道两个值都是字符串类型，并且您想确保上述边缘情况不会像'0.0' !== '0'那样触发，只需使用assertSame 。 基本上 assertEquals 现在是 assertEquals 和 assertSame 的混合，具体取决于类型，这使得行为根本不明显。

FWIW，要么事情是平等的，要么不是：你需要弥补
你对你的代码是否遵循这个非常基本的原则的看法
与否，因为==肯定不再是合适的等价物
无论如何，根据测试资产中的发现，操作符（或操作码）
这里。

2018 年 10 月 11 日星期四，17:34 Tobias Schultze， notifications@ github.com
写道：

我们也受到这次严重的公元前中断的影响。 虽然我同意边缘
#58 https://github.com/sebastianbergmann/phpunit/issues/58中的案例是
不好，应该避免，我不认为为此更改 assertEquals
是正确的举动。 AssertEquals 一直是（对我来说），关于松散
可能包括类型杂耍的比较。 如果你知道这两个值
是字符串类型，并且您想确保上述边缘情况不会
触发像 '0.0' !== '0'，只需使用 assertSame。 基本上 assertEquals
现在是 assertEquals 和 assertSame 的混合，具体取决于类型
使行为根本不明显。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/sebastianbergmann/phpunit/issues/3185#issuecomment-429000073 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAJakG73OfK6Ki-kh1rPiudasXyFVqc8ks5uj2TzgaJpZM4U3XOz
.

在我们的例子中，我们将 assertEquals 用于货币值（显然表示为字符串）并依赖于忽略尾随零的事实（因为内部表示可能使用更多的小数）。

因此，给我的@Ocramius使用$self::assertEquals(0, '0.00')的解决方法也不起作用，因为您没有将货币表示为浮点数，而是表示为字符串。 所以这两个值总是字符串，但现在 assertEquals 抱怨到处都是不匹配的尾随零。

一个解决方案是提供一个新的断言，忽略以字符串表示的数值的尾随零，这也是@IanVS报告的问题

此问题已自动标记为过时，因为它在过去 60 天内没有活动。 如果没有进一步的活动，它将在 7 天后关闭。 感谢你的贡献。

此问题已自动关闭，因为它自标记为陈旧后就没有活动。 感谢你的贡献。