我应该单元测试继承自超类的方法吗?

时间:2009-01-01 19:17:32

标签: java unit-testing tdd junit

我目前正在以TDD方式编写JDBC驱动程序的实现(是的,你正确读取),而我此时只完成了类存根,只有一些次要功能,它只是发生在我身上,因为StatementPreparedStatement的超类,它是CallableStatement的超类,当我真正开始为这些类的实现编写测试时,我该怎么办,我应该做以下哪一项:

  1. Statement创建一个测试套件,然后扩展该套件以进行PreparedStatement的其他测试,然后对CallableStatement执行相同操作。
  2. 单独测试每个实现,忽略从超类继承的方法。
  3. 为每个实现类单独严格测试每个方法;根据实现,一些继承的方法可能会有所不同。轻微的变化就是我会测试实现使用的所有继承方法。
  4. 二号感觉最自然,但由于我放到第三个的原因,我不确定这样做是否明智。那么,认为我该做什么?

4 个答案:

答案 0 :(得分:9)

“为每个实现类单独测试每个方法”

特别是,未能正确覆盖超类方法是一个常见的错误。子类的作者对超类做出假设。超类发生了变化,子类现在被破坏了。

答案 1 :(得分:7)

如果这意味着您将为每个测试子类重复运行相同的测试,那么我将永远不会做替代1(让测试类层次结构与实际的类层次结构相同)。我一般也对除了通用实用程序基类之外的测试类的子类化持怀疑态度。

我通常对层次结构中的每个类进行1次测试,抽象与否。所以基类有一个单独的测试(通常有一个测试本地私有子类,用于专门测试它),我使用我的子类知识为每个子类编写适当的测试。我可以在报道中看到缺少测试的内容,所以我通常不会过于正式化。

答案 2 :(得分:4)

根据您对实施的了解,提供足够的测试以使您感到舒适。我不认为单元测试是完全黑盒测试。如果您知道基类从不调用任何虚拟方法(或者至少没有被覆盖的方法),那么请注意这一事实,但不能有效地复制您已经获得的单元测试。

单元测试肯定可以达到极限 - 总是值得平衡你从中获得的价值与你花费的成本。

答案 3 :(得分:2)

使用TDD,您不应该针对测试方法,而是针对代码的行为或功能。因此,在实现子类时,您可以限制仅测试与基类不同的行为。如有疑问,请写一个新的测试。