在单元测试，方法或场景中测试什么？
如果测试每种方法，则需要最小的测试用例设置。
如果测试调用其他方法的方法，那么测试用例所需的设置是巨大的。如果单个方法的单元测试已经存在，那么为什么要编写使用它们的方法呢？
但是它也有一些应该测试的功能。此外，代码覆盖工具会抱怨覆盖百分比。
请提供您的实际意见。
答案 0 :(得分：3)
如果测试一个调用其他的方法 然后设置所需的方法 测试用例是巨大的。如果是单元测试 个别方法已经存在 那么为什么要写这个呢 使用它们的方法？
因为该方法可能使用错误的参数或错误的序列调用底层方法，或者使用返回值执行错误操作。
根据我的经验，与它们之间的相互作用以及这种“胶水代码”相比，自包含方法中出错的可能性通常很小。
“经典”单元测试，你完全测试每个类的行为是一个很好的概念，但实际上，这种情况并不是那么常见或有用。这取决于为模块化设计代码需要多少注意力，并且（隐含于此）可测试性，但它永远不可能实现一切。
答案 1 :(得分：2)
您对一个方法进行单元测试，每个可能的执行路径都有一个测试用例。
单元测试的典型结构是Arrange-Act-assert（三A）：
过度设置应该表明你应该看看你的设计，例如，你的课程可能太大，或做太多事情。 Excessive setup是一种反模式。
您可以使用mock objects来隔离您正在测试的课程。
答案 2 :(得分：2)
单元测试的一号规则是：
一次只测试一件事！
这意味着：您甚至不测试方法，在单一条件下测试方法的单个方面。所以你为同样的方法提出了几个测试。
隔离是良好单元测试的关键。您需要模拟您的依赖项（例如，使用RhinoMocks）。一开始它看起来更复杂，但从长远来看，它更容易管理和维护。在测试中只测试少量代码，让您尽可能地进行测试，并且您将进行可维护的测试。