Question

鉴于以下SUT，您是否认为此单元测试不必要？

**编辑：我们不能假设名称会匹配，因此反射不起作用。

**编辑2：实际上，这个类将实现一个IMapper接口，并且应用程序的业务逻辑层将进行全面的行为（模拟）测试。这个测试恰好是必须基于状态的最低级别的测试。我怀疑这个测试是否真的有必要，因为测试代码几乎与源代码本身完全相同，并且根据实际经验，我没有看到这个单元测试如何使应用程序的维护更容易。

//SUT
public class Mapper
{
  public void Map(DataContract from, DataObject to)
  {
    to.Value1 = from.Value1;
    to.Value2 = from.Value2;
    ....
    to.Value100 = from.Value100;
  }
}

//Unit Test
public class MapperTest()
{
   DataContract contract = new DataContract(){... } ;
   DataObject do = new DataObject(){...};
   Mapper mapper = new Mapper();
   mapper.Map(contract, do);
   Assert.AreEqual(do.Value1, contract.Value1);
   ...
   Assert.AreEqual(do.Value100, contract.Value100);

}

Answer 1

我会质疑构造本身，而不是测试它的必要性

[反射将远远少于代码]

Answer 2

我认为这是必要的。但是，它会更好地作为100个单独的单元测试，每个测试检查一个值。这样，当您value65出现问题时，您可以运行测试，并立即发现value65和value66正在转置。真的，这是一种简单的代码，你可以将脑子切掉，忘掉那些错误。进行测试意味着你选择它们而不是你的客户。

但是，如果你有一个100个属性的类都名为ValueXXX，那么你可能更适合使用数组或列表。

Answer 3

如果您可以在更高级别进行测试，即需要您创建Mapper.Map（）函数的业务逻辑，那会更好。

Answer 4

这并不过分。我肯定不确定它是否完全专注于您想要测试的内容。

"Under the strict definition, for QA purposes, the failure of a UnitTest implicates only one unit. You know exactly where to search to find the bug."

单元测试的功能在于具有已知的正确结果状态，焦点应该是分配给DataContract的值。这些是我们想要推动的界限。确保可以将DataContract的所有可能值成功复制到DataObject中。必须使用边缘大小写值填充DataContract。

PS。 David Kemp是正确的，100个精心设计的测试对于单元测试的概念是最真实的。

注意：对于此测试，我们必须假设DataContract在构建时完美填充（需要单独的测试）。

Answer 5

如果这是整个应用中唯一的此类单元测试，请不要这样做。然而，第二个像它出现的那样，你会看到我蜷缩着眉毛，开始考虑反思。

Answer 6

不过分。

我同意代码看起来很奇怪，但是说：

单元测试的美妙之处在于，一旦完成就会永远存在，所以如果任何人出于任何原因决定改变实现以获得更“聪明”的东西，那么测试应该通过，所以没什么大不了的。

我个人可能会有一个perl脚本来生成代码，因为我会厌烦更换每个断言的数字，我可能会在路上犯一些错误，并且perl脚本（或者什么是脚本）会对我来说更快。

这个单元测试是否过度？

6 个答案: