我可以在单元测试中这样做吗？

Question

我不确定我应该在这里做什么。我应该硬编码所有值还是应该将它们放在 CONST 变量中。我看到的所有内容似乎都对其中的值进行了硬编码，所以我不确定。

这就是我现在正在做的事情。

假设我在控制器中进行了验证测试，以检查用户是否尝试提交带有空白字段的表单。

现在我将有一个 if 语句检查空白或空变量。如果发生这种情况，我会将错误添加到 ModelState 中，并附上我写的错误消息。

所以在我的单元测试中，我想确保如果提交了一个空白表单变量，它会被捕获。

现在在我的单元测试中，我刚刚创建了一个 CONST 变量并复制并粘贴了验证消息。

所以在我的断言中，我将实际消息与存储在我的 CONST Varrible 中的消息进行比较。我通过调用模型状态来执行此操作，并调用我期望错误所在的字段。

喜欢：

result.ViewData.ModelState["username"].Errors[0];

所以如果消息在那里，那么它一定已经进入了我的代码，否则它就不会存在。

所以我想到也许我应该创建一个静态的新类并保存所有这些 CONST 变量。

这样控制器视图和单元测试都可以使用它们。这样，如果我要更改错误消息，那么我只需要更改一个地方。因为我没有测试错误消息是什么，所以我正在测试它是否被设置。

同样的事情说异常我有一些自定义消息，但我没有测试消息是否正确，如果期望被捕获则更多。

我测试它的方式是查看消息是否是我期望的消息，因为如果它不是消息或消息不存在，那么就出了问题。

我是单元测试的新手，所以我想确保我要做的事情不会搞砸我的单元测试。

对我来说这是有道理的，但我认为最好先检查一下。

谢谢

Answer 1

以对后续更改稳健的方式编写每个测试非常重要。您经常需要在以后更改应用程序的某些部分，并且每次这样做时，都有可能会破坏您的多个测试。

如果您的测试对更改具有稳健性，那么失败的测试将真正表明存在回归错误。

但是，如果您的测试是所谓的过度指定测试，那么您在代码库中所做的每一个小改动都可能导致测试失败 - 不是因为存在回归错误，而是因为测试太脆弱。当这种情况发生时，你就会对你的测试失去信心；测试维护需要大量时间，最终您会完全放弃测试套件。

当我阅读您的问题时，您已经开始看到这种反模式的轮廓。我认为这就是为什么您不测试返回的特定文本的原因，而只是测试它们是否被设置。我认为这是正确的——我很少测试特定的字符串，而是测试是否指定了一个字符串。这使测试更健壮，更易于更改，并且您避免了 Overspecified Test 反模式。

在许多情况下，您可以只使用 Assert.IsNotNull 或 Assert.IsFalse(string.IsNullOrEmpty(result))（您的平台似乎是 .NET），而不是对两个字符串执行 Assert.AreEqual。

一般而言，基于派生值的断言非常容易更改，因此您可能需要查看以下博客文章：

• Derived Values Ensure Executable Specification

如果你觉得特别有冒险精神，我只能建议你阅读xUnit Test Patterns，我提到的许多模式和反模式都来自这里。 The Art of Unit Testing也不错……

Answer 2

“我应该将所有值硬编码在 CONST 变量中还是应该将它们包含在 CONST 变量中。”

我不确定你的意思。在单元测试类中有 const 变量很好。例如：

class FooTest
{
    private static readonly string FOO_MESSAGE = "BAR"; 

或

    public static const string BAZ_MESSAGE = "BOO";

...

    Assert.AreEqual(FOO_MESSAGE, e.ToString());
}

“所以我想到也许我应该创建一个新的静态类并保存所有这些 CONST 变量。

这样控制器视图和单元测试都可以使用它们。这样，如果我要更改错误消息，那么我只需要更改一处即可。”

这似乎是错误的。控制器用来输出错误的机制是它私有的。这不应该不必要地暴露在单元测试中。通过这样做，您显然更有可能使错误未被发现。控制器和测试将“同意”，因为它们使用的是相同的半公开机制。

“由于我没有测试错误消息是什么，所以我正在测试它是否被设置。”

如果你真的不测试消息，为什么测试甚至会知道它？