unit-testing - 在描述的案例中寻找可测试的设计

Question

我有一个系统，它以某种 ABC 格式从外部系统获取对象列表，将其转换为内部表示并传递给外部服务:

class ABCService() {
  public ABCService(ExtService extService) {
    this.extService = extService;
  }

  public void do(ABCData [] abcObjs) throws NoDataException {
    if (abcObjs.length == 0) {
      throw NoDataException();
    } else {
      List<Data> objs = new ArrayList<>();

      for (ABCData abcObj : abcObjs) {
        Data obj = Parser.parse(abcObj); // static call
        objs.add(obj);
      }

      extService.do(objs);
    }
  }
}

在测试 ABCService 时，我们可以测试两件事:

• 如果没有数据传递给“do”，服务抛出异常；
• 如果一些数据被传递给“do”，服务应该调用 extService 并传递完全相同数量的对象，它已经从测试调用者那里收到。

但是，虽然 Parser factory 也经过测试，但不能保证输出“objs”数组以某种方式连接到输入 abcObjs(例如，方法已创建具有预定义长度的列表，但方法“忘记”填充列表) .

我认为这两个测试用例没有完全涵盖方法的工作流程，导致其中一些未经测试是很危险的。

如何修改 ABCService 设计以提高其可测试性？

Answer 1

此代码的主要测试困难在于您有两个协作者，其中一个是静态的。

如果您可以将您的 Parser 转换为非静态(或者可能将其包装在非静态中)并像执行 extService 一样注入(inject)它，您可以测试使用正确的参数调用解析器的次数是否正确。插入解析器的返回值，您还可以验证是否使用适当转换的对象而不是正确数量的对象调用您的 extService。