1

What to test in unit testing, a method or a scenario?

If test each method then minimal test case setup is required.

If test a method which calls other methods then setup required for the test case is huge. If unit-tests for the individual methods are already there then why to write for this method which is using them?

But then it also have little bit of functionality which should be tested. Also the code coverge tool will complain about coverage percentage.

Please provide your practical inputs.

4

3 回答 3

3

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

因为该方法可能会使用错误的参数或以错误的顺序调用底层方法，或者对返回值执行错误的操作。

根据我的经验，与它们与此类“胶水代码”之间的交互相比，自包含方法中出错的可能性通常很小。

“经典”单元测试，您完全独立地测试每个类的行为是一个不错的概念，但实际上，这种情况并不是那么普遍或有用。这取决于在设计代码的模块化和（隐含的）可测试性方面花了多少心血，但永远不可能做到所有事情。

于 2009-04-20T10:05:54.707 回答
2

第一法则是：

一次只测试一件事！

这意味着：您甚至不测试方法，而是在单一条件下测试方法的单个方面。所以你想出了几个测试相同的方法。

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

于 2009-04-21T06:58:30.607 回答
2

您对一个方法进行单元测试，每个可能的执行路径都有一个测试用例。

单元测试的典型结构是 Arrange-Act-assert（三个 A）：

  • 安排 - 为您要测试的案例创建环境（这可以在套件设置或测试案例中完成，或两者兼而有之）
  • Act - 测试用例调用被测方法
  • 断言 - 验证被测方法是否完成了它应该做的事情

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

您可以使用模拟对象来隔离您正在测试的类。

于 2009-04-20T11:23:30.510 回答