在单元测试，方法或场景中测试什么？

Question

在单元测试，方法或场景中测试什么？

如果测试每种方法，那么最小的测试用例设置是必需的。

如果测试调用其他方法的方法，那么测试用例所需的设置是巨大的。如果单个方法的单元测试已经存在，那么为什么要编写这种使用它们的方法呢？

但是它也有一点功能，应该测试。代码覆盖工具也会投诉覆盖率。

请提供您的实际意见。

Answer 1

如果测试它调用其他方法 然后为 测试用例要求的设置的方法是巨大的。如果单元测试为 单个方法已经是 那么为什么要写这个 方法正在使用它们？

因为该方法可能会调用带有错误参数或错误序列的底层方法，或者使用返回值做错误的事情。

根据我的经验，自包含方法中的错误潜力通常比它们与这种“胶水代码”之间的交互相比要小。

“经典”单元测试，您完全测试每个类的行为是一个很好的概念，但实际上，这种情况并不是那么常见，也不是很有用。这取决于设计模块化代码和（可隐含）可测试性需要多少注意力，但是不可能为所有事情做到。

Answer 2

您可以对每个可能的执行路径使用一个测试用例进行单元测试。

的单元测试的典型结构是排列，法，断言（三A的）：

• 安排 - 创造您想要测试的情况下，环境（这可以在套房安装完成或在TestCase的，或两者）
• 法案 - 测试用例调用
• 断言测试方法 - 验证测试方法没有什么是应该做的

过多的设置应该是这表明你应该看看你的设计，例如，你的班级可能太大，或者做了太多事情。 Excessive setup是一种反模式。

您可以使用mock objects隔离您正在测试的类。

Answer 3

的头号单元测试的规则是：

只测试一两件事一次！

这意味着：你甚至不测试一个方法，你在一个条件下测试一个方法的一个方面。所以你为同样的方法提出了几个测试。

隔离是良好的单元测试的关键。你需要嘲笑你的依赖（例如使用RhinoMocks）。一开始看起来更加复杂，但从长远来看，管理和维护要容易得多。在测试中只测试少量代码，使得测试尽可能平凡，并且您将拥有可维护的测试。