Question

我们是否应该测试我们已经知道答案的值？

如果一个值足够重要，可以作为一个专用的硬代码值，那么它是否应该足够重要，以便在值的同时更改测试？或者这只是矫枉过正？！

Answer 1

如果通过“硬编码属性”，你的意思是这样的（在Java中）：

int getTheAnswer() {
    return 42;
}

然后你需要问问自己 - 为什么不让它成为常数？例如，

static final int THE_ANSWER = 42;

在这种情况下，您无需对其进行单元测试。

在所有其他情况下，您应该考虑单元测试。

Answer 2

需要更多背景来回答您的问题。这取决于。你的getXXX方法是从另一个正在测试的方法中调用的吗？如果是这样，那么它已经过测试。如果没有，客户端在做什么？该方法甚至需要存在吗？

Answer 3

如果您使用TDD开发代码，那么您的单元测试就是首先创建硬编码属性的内容。

Answer 4

不，但更好的问题是为什么你硬编码值？我知道有时你的系统范围的配置设置很少（或从不）改变，但理想情况下，即使那些应该是可配置的，因此应该进行测试。永远不会改变的值仍然可以通过命名良好的常量来访问。如果您的系统仍处于早期开发阶段，可能还没有构建这些组件，所以不要担心测试它们。 ;）

嗯好的我猜这些例外可能是数学或物理常数。

Answer 5

除了其他答案的明显要点外：

您可能还想添加一个集成测试，以验证您的硬编码值是否真正有效并且可以很好地与其他组件配合使用。

有时你做需要硬编码值，即在实现要求进行能力测试的接口时，例如

interface IDecoder { // in C#
    bool SupportStreaming { get; }
}

当然，在实现上面的IDecoder接口时，您必须对SupportStreaming属性的值进行硬编码。

但重要的问题当然不是天气它会返回硬编码值吗？但是天气硬编码的值实际上是正确的值吗？，这只在进行集成测试和/或测试依赖于值的其他单位/方法时才有意义。

Answer 6

我们是否应该测试我们已经知道答案的值？

你怎么知道的？有人可能已经更改了代码，作为回归，它现在返回其他内容。

如果这些值是公共API的一部分，您应该测试它们。

你应该根据文字值来测试它们，而不是你正在测试的程序定义的常量（因为那些可能在错误中被改变了）。

 // good
 assertEquals( "Number", myClass.getType(1234));
 assertEquals( "Number", MyClass.TYPE_NUMBER);

 // not so good
 assertEquals( MyClass.TYPE_NUMBER, myClass.getType(1234));

Answer 7

我个人不打算测试任何声明性的内容。

你应该单元测试硬编码属性的返回值吗？

7 个答案: