涵盖分支案例的单元测试

Question

我正在尝试使用 mocha 为以下 .js 编写单元测试

const fs = require('fs')
const defaultValue = 255

const envValue = process.env.Var1Value
const valueToUse = envValue && !isNaN(envValue) ? parseInt(envValue) : defaultValue

module.exports.MyFun = () => {
  //use the value of 'valueToUse'
}

在我的单元测试中，我试图涵盖来自环境和默认值的 "valueToUse" 案例。我试图了解如何涵盖单元测试的两种情况。如果我在加载模块之前设置 process.env.Var1Value（使用 require），它涵盖第一种情况，但不涵盖另一种情况，如果我不设置 env 变量，则相反，它涵盖另一种情况，因为模块只被加载一次......我应该如何进行涵盖这两种情况的单元测试？提前致谢！

Answer 1

让我们假设您当前的启动代码确实必须在启动时计算。然后你会得到一些解决方案，其中可执行文件被多次启动，例如从 shell 脚本。然后可以通过一些命令行参数将要执行的测试中的哪些测试传递给测试的 main 函数。这是可能的，但通常没有必要这样做。

另一种选择是将启动代码转换为可以在测试代码的控制下重新执行的代码 - 例如，以某种 init() 函数的形式计算 global/static变量。对于生产代码的启动，这不会对性能产生很大影响，并且在生产代码中 init() 函数实际上只会计算一次。对于运行时间的表现，根本没有惩罚。然而，对于单元测试，这带来了一个优势，即您可以随意调用 init()。

您可以更进一步，将 valueToUse 的计算包装到它自己的函数中，这样 init() 调用此函数来设置 valueToUse 的值。好的一点是，这个函数也可以通过单元测试单独测试。同样，在启动期间只有轻微的性能损失，但在执行期间不会。

不可否认，所有这些都是权衡：您也不能将变量归类为 const 等。但是，这就是为什么有一个叫做 "design for testability" 的概念：因为可测试代码有时看起来与未测试代码不同专为可测试性而设计。

涵盖分支案例的单元测试

unit testing covering the branch case

unit-testing

mocha.js

node.js