减少测试用例之间的耦合

crl*_*ane 7 java testing tdd junit unit-testing

我正在尝试了解有关JUnit和TDD的更多信息,但我遇到了测试用例之间耦合的一些问题.

当我为特定数据类型的API编写测试用例时,比方说a Deque<T>,如何限制测试用例之间的耦合?例如,如果我正在为该方法编写一个测试用例insertFirst(T item),那么假设我应该能够在正确初始化的对象上调用该方法之后断言两件事,这似乎是直截了当的:

  1. Deque对象的大小应该增加一个
  2. 如果我随后调用相应的T removeFirst()方法,它应该返回对我通过初始调用插入的对象的引用.

但是,这会在我的至少两个测试用例之间产生不希望的耦合,其中一个测试用例传递依赖于另一个API方法的正确实现.例如,为了使这个测试用例通过,我需要一个正确的实现来检查项目的数量Deque以及删除项目.如果我对这些方法中的任何一个的测试由于某种原因不正确或不完整,那么我对该insertFirst方法的测试将自动被怀疑.

避免这种情况的最佳做法是什么?我的方法是否以某种方式编写测试用例错误?

Dan*_*rth 12

在为一个方法编写测试时,您必须假设其余类正在运行.如果你不做这个假设,唯一的结论就是每个班级进行一次大规模的测试.这不是我们所做的.

您可以假设该类的其他部分正常工作,因为还会对其他部分进行测试,以确保其正确性.
如果一个部件工作不正常,测试将失败,显示某些内容不正确.
一旦测试套件测试失败,就必须修复错误.你不再做任何假设.

例:

您有一个简单的列表实现,只有三种方法:

  1. 插入
  2. 去掉
  3. 计数

你有三个测试:

  1. 测试insert:
    • 创建列表实例(安排)
    • insert项目(法案)
    • 检查count等于1(断言)
  2. 测试remove:
    • 创建列表和insert项目的实例(安排)
    • remove项目(法案)
    • 检查count等于0(断言)
  3. 测试count:
    • 创建列表实例和insertn个项目(安排)
    • 检索count(法案)
    • 检查count等于n(断言)

现在,如果上述任何测试失败,您无法确定您班级的单个成员的正确性:

  • 如果第一次测试失败,第三次测试也将失败.第二个将通过,但实际上没有测试remove,因为没有什么可以删除.
  • 如果第二次测试失败,其他两个测试仍然会通过.但是,您无法确定insert并且count正常工作,因为如果三个成员中的任何一个无法正常工作,则第二个测试将失败.
  • 如果第三次测试失败,另外两次最有可能失败.

失败的测试告诉您一些事情:
根据失败的测试,您通常可以减去错误的位置.
示例:如果只有第二个测试失败但不是第一个或第三个测试失败,则错误很可能是在remove方法中.

  • 好吧,这是有道理的。所以我的错误在于我如何解释单个测试用例的传递。如果对单个方法的测试通过,则_NOT_ 表示该方法是正确的。如果我编写了一个完整的测试套件来正确测试 **所有** API 的方法,我只能假设我的方法是正确的。这有帮助。再次感谢。 (2认同)
  • +1,我想补充一点,你正在测试的东西是方法调用的意外副作用,因此对其他方法的测试依赖性不仅是可以容忍的,而且是有用的. (2认同)