在编写单元测试时是否有任何自动化工具可以找到类依赖项。
显示我的意思的一个例子:
我们想为类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可视化依赖项。