8

我目前正在以 TDD 方式编写 JDBC 驱动程序的实现（是的，你没看错），虽然此时我只完成了类存根并且只有一些次要功能，但我突然想到，因为Statement它是一个超类对于PreparedStatementwhich 是 的超类CallableStatement，当我真正开始为这些类的实现编写测试时，我应该怎么做，我应该做其中的哪一个：

  1. 创建一个测试套件Statement，然后扩展该套件以进行其他测试PreparedStatement，然后对CallableStatement.
  2. 单独测试每个实现，忽略从超类继承的方法。
  3. 为每个实现类单独严格测试每个方法；毕竟，某些继承的方法可能会因实现而有所不同。这一点的轻微变化是我会测试实现使用的所有那些继承的方法。

第二个感觉最自然，但由于我放在第三个的原因，我不确定这样做是否明智。所以，你觉得我应该怎么做？

4

4 回答 4

11

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

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

于 2009-01-01T19:38:42.103 回答
7

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

我通常对层次结构中的每个类进行 1 次测试，无论是否抽象。所以基类有一个单独的测试（通常带有一个用于专门测试它的本地测试私有子类），我利用我对子类的了解为每个子类编写适当的测试。我可以在覆盖运行中看到缺少的测试，所以我通常不会提前正式化。

于 2009-01-01T19:24:59.447 回答
4

根据您对实现的了解，提供足够的测试让您感觉舒适。我不将单元测试视为完全的黑盒测试。如果您知道基类从不调用任何虚拟方法（或至少没有被覆盖），那么请注意这一事实，但不要有效地复制您已经获得的单元测试。

单元测试当然可以走极端——平衡你从中获得的价值和付出的努力总是值得的。

于 2009-01-01T19:21:15.087 回答
1

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

于 2009-01-01T19:35:28.350 回答