在Node的另一个方法中声明的单元测试方法

时间:2019-02-21 06:47:36

标签: javascript node.js unit-testing reflection sinon

我具有以下格式的节点模块

'use strict’;

/// require dependencies here 

function outerFunc1(a, b, c) {

  function f1() {
    return f2()
  }

  function f2() {
    return 2
  }
  f1();
}
const choose = (type) => {
  let funcToCall
  switch (type) {
    case "func1":
      funcToCall = outerFunc1;
      break;
  }
  return funcToCall;
}

module.exports = (function () {
  return {
    choose
  };
})();

任何人都可以告诉我如何对功能f2和f1进行单元测试,或者换句话说,我该如何调用功能,是否有任何方法可以像使用反射API或通过其他方式使用rewire或sinon来实现相同功能?

1 个答案:

答案 0 :(得分:0)

mainmain的所有功能都可以轻松地从公共API函数间接地激发。因此,没有充分的理由自己进行测试。相反,有理由再次对其进行单独测试:每当更改f1的实现时,f2outerFunc1受到破坏测试的影响的可能性似乎很高。

但是,请注意,我通常不反对测试实现细节:您应该绝对设计测试,以便可以发现所有潜在的错误-这意味着您应该考虑实现细节。单元测试是正确的方法,因为单元测试的目的就是使用白盒知识来测试代码中最小的可测试实体。例如,当您使用分支覆盖率分析来查看是否错过了某些测试时,就是在利用有关代码控制结构的白盒知识。

有些人认为您不应该测试实现,而应该测试行为。原因是否则测试套件可能会变得脆弱。虽然避免测试套件变得不必要的脆弱无疑是一个有效的目标,但这并不是最高优先级。 IMO的最高优先级是可以找到生产代码中的所有错误。这还需要测试实现细节。

如果某些计算使用缓存来更快地重新生成已计算的结果,那么从用户的角度来看,这将是实现细节。但是,当然,缓存算法可能包含错误,因此应该测试缓存。更一般而言,更大系统的每个子系统(小型或大型)都可以看作是大型系统的实现细节。但这并不意味着只能在系统的最外面进行测试。