C# 对值对象进行单元测试

有必要对值对象进行单元测试吗？您将如何进行

以这个对象为例：

public class TeamProfile
{
    public string Name { get; set; }

    public int Wins { get; set; }
    public int Losses { get; set; }
    public int Draws { get; set; }
}

我不认为这本身是“必要的”，但它确实可以保护您，以防您在某个时候向二传手添加逻辑（例如：在尝试负赢/负输/平局时引发异常，因为您没有使用无符号整数）

---

如何测试它？简单：调用setter，调用getter，验证该值是否为您存储的值，或者引发您期望的异常。

可以这样做，但完全无用。

---

值对象绝对不包含逻辑，因此测试它们是白费力气的（如果您的值对象被破坏，那么几乎所有其他测试都会被破坏，因为您从未模拟它们）。

我不测试短样式属性。后面的代码是由编译器自动生成的，所以我不明白为什么要测试它们

---

只要记住，在更改排序签名后立即添加缺少的测试。

我将测试不只是简单的get/set的功能。例如，值对象应该覆盖Equals和GetHashCode

---

如果您认为单元测试是一个编码的功能规范，那么这可以帮助您想出所需的测试。（如果您真的有一个功能规范，那么这是确定单元测试的一个很好的来源。）

答案是意见。我想说不。但这些问题在日常工作中确实会出现，我理解这个问题，所以让我给出一些更多的意见：

我会根据具体情况来判断。如果你认为“我的单元测试例程可以测试所有的东西”（并且依赖于它），并且你看到上面的例程可能会朝着更复杂的方向改变，那么答案是肯定的。像这样的问题，我有时会回答“是”，但过了一段时间，我才发现这真是太过分了。然后在其他场合，我判断“哦，天哪，这真是太过分了”，后来才发现有一个方面我从来没有想过

---

如何测试它？作为所有测试用例：定义输入和预期结果。设定它。了解了。检查get是否是您所设置的。

Dan Bergh Johnson有一篇关于值对象及其介绍和测试的优秀文章

为清楚起见，我必须重申，给出的示例不是一个价值对象。

它特别是一个命令、消息或更可能是一个（DTO）数据传输对象

---

正如其他人所提到的，提供的类没有需要测试的行为。

您会对它进行什么测试？您相信编译器会生成正确的代码吗？如果是这样，这里就没有要测试的行为。您还可以测试一个raw

int

+1，以指出OP示例的一个重要方面—在本例中生成了getter和setter—无需验证它们是否工作，只需信任编译器即可。然而，在您编写该代码x年后，初级程序员可能会扩展您的“短”getter或setter，并向其中添加一些“业务逻辑”（例如，将值四舍五入到“最接近的10”）。是的，其他一些测试也会失败，但这些测试并不能让孩子找到真正的问题所在。年轻人可能会通过“纠正”他们的断言来修正这些测试，然后继续。。。更好的结果是，类的单元测试失败，并明确解释，例如，“该类的实例打算用作DTO，即每个getter必须返回提供给其相应setter的最后一个值”。