在编写单元测试时是否有任何自动化工具可以找到类依赖项。
显示我的意思的一个例子：
我们想为类ToBeTested编写单元测试。所以我将编写一些测试来验证类的预期行为。现在我仍然不知道是否存在类依赖，因为ToBeTested可能使用了许多其他类。这一点很重要，因为我们希望打破这些依赖关系，或者至少确保它们是安全的（已经过测试）。
到目前为止，我发现找到依赖关系的最佳方法是使用eclemma，它给出了一个包含在测试期间运行的代码的类列表。
但是我知道我手动输入这些类，是否有更简单/自动的方法来获取这些类，甚至在我的java程序中使用这个列表。
编辑：对不起，我正在使用eclipse和java。
答案 0 :(得分：5)
由于单元测试（几乎总是）白盒测试，您只需查看正在测试的类的源代码即可查看其依赖项。
某些自动化工具产生的依赖关系列表在理论上可能听起来不错，但根据我的经验，无论如何都不会有太多帮助 - 您需要逐个查看依赖关系< / strong>，从当前测试的角度确定哪些是真实的，重要的，然后为他们的单元测试正确设置/模拟它们。这部分不能自动化（我怀疑它会永远）。
实现这一目标的最简单和最好的方法是使用最简单的明显测试夹具（即通常为ToBeTested tested = new ToBeTested()）开始运行测试。如果成功，我将call（s）添加到对象上的所需方法。如果这也成功（即没有抛出运行时的异常），我添加断言。如果（当）任何这些步骤失败，我会查看/调试代码以查看出错的地方，并扩展测试夹具以覆盖它。
在最好的情况下（你自己的代码上的TDD，正在新开发）这个过程当然要简单得多，因为这个类从一开始就被设计为可测试的，因此它具有最少的依赖性，你已经知道这些。在最糟糕的情况下（编写遗留代码的单元测试），这可能是一个痛苦但有益的探索和可能的重构过程，花费几个小时来创建第一个工作测试。但是接下来会更容易，在第3次之后我几乎总是开始生产更多的测试，如传送带。
答案 1 :(得分：4)
是的，一个是JDepend，它分析包依赖项。我们使用它来自动检测包之间的周期性依赖关系。我不知道检查测试本身的依赖是多么容易。
有关使用JDepend与单元测试的更多详细信息，请参见http://www.clarkware.com/software/JDepend.html#junit。
还有corresponding Eclipse plug-in可视化依赖项。