Question

在使用任何语言进行测试时，每个人如何表达他们的断言信息？

我看到三种显而易见的方式：

# assume failure
assert (4-2) == 2, "Subtracting 2 from 4 doesn't equal 2"

# describe success
assert (4-2) == 2, "Subtracting 2 from 4 should equal 2"

# be vauge with failure
assert (4-2) == 2, "Subtracting 2 from 4 is broken"

这显然是一个简单的例子，但你明白了。什么是标准做法？你是做什么？为什么呢？

Answer 1

我不知道标准做法是什么，但我将前两种方法与增加的实际结果相结合。

"Substracting 2 from 4 should equal 2, but equals " + value

这不容置疑，并且易于调试。

Answer 2

断言的重要之处在于测试的实际条件。在C中，您可以使用预处理器“stringization”来输出正在测试的实际条件。我的代码只输出

Assert Failed: (4-2)==2 : Line 123, File foo.c

如果你很幸运，你也可以获得堆栈转储......

Answer 3

我不知道是否有任何“标准”，但在大多数情况下，我喜欢看到断言条件本身。 C自动执行此操作。在C＃中，我不得不复制粘贴它，例如，

Debug.Assert(4-2==2, "4-2==2");

在某些情况下，查看比条件提供的信息更有用。在这种情况下，我将断言消息视为错误消息并说明错误，例如。

Debug.Assert(result != null, "No result returned for input '" + input + "'");

Answer 4

我将断言消息视为注释：如果我可以避免它，我尽量不要使用它们，如果我可以从代码中清除它的意图。

通常，当您想要断言的某些属性以某种方式相关时，这是一个问题。将断言提取到一个名为表示您感兴趣的方面/关系的方法中，可以更明显地发生什么，而无需维护评论/消息。

Answer 5

与IMO无关，只要错误消息告诉您出了什么问题以及问题出在哪里。在正常操作下，永远不会看到断言消息。如果看到，代码中的某个地方存在错误，您需要能够追踪并修复错误。

该消息应提供尽可能多的有用信息 - 如果您检查两个值是否相等而不是，则应打印出值。这样就无需使用调试器来检查值。当然，这样做需要您的语言支持断言消息中的非静态信息。如果只能修复断言消息，静态字符串，则无法在不跳过循环的情况下添加额外的运行时信息。

Answer 6

罗迪的建议很好 - 它肯定会使添加新断言的“成本”更便宜（即不需要考虑或输入新的字符串消息）。信不信由你，但实施他的建议对我对断言的使用产生了重大影响。

如果您仍在寻找更清晰的短信，您可能会考虑以下内容：

“预计4-2等于2”

这似乎表明（至少对我来说）预期的答案是2，但是没有达到期望......

Answer 7

我使用断言消息来记录断言正在测试的内容，或者预期值是什么。

有时，当测试失败时，我不需要查看失败的测试：只是从断言消息和我刚刚做出的更改，我知道如何解决它。

断言消息：假设失败或假设成功

7 个答案: