如何在反应组件之外测试私有功能答案

【问题标题】：how to test private function outside react component如何在反应组件之外测试私有功能
【发布时间】：2019-02-11 19:26:32
【问题描述】：

我在组件之外有一个私有函数。单独测试功能听起来比在 MyComponent 中测试更方便，但它是私有的，没有导出。

function func(){
 return something;
}

export default class MyComponent extends Component {

render <SomeComponent someProp={func()} />
}

我使用mocha 和enzyme 进行测试，我想知道是否有测试私有函数而不是在组件内部测试它。

【问题讨论】：

是的，导出它？
你错过了这里的重点，在这种情况下你正在删除私有函数的概念
你不能测试私有函数，它们不应该被单独测试，因为它们应该是内部实现的一部分。
unit testing of private functions with mocha and node.js的可能重复
如果你想单独测试它，然后导出它。如果您认为它是私有的并且不应该被导出，那么您需要通过您的其他代码进行测试。我看不出 React 如何帮助你解决这个问题或与问题有关。是的，我正在努力提供帮助。否则我不会看你的问题。

标签： javascript reactjs mocha.js enzyme

【解决方案1】：

func 在模块范围内定义。无法访问它们在 JavaScript 中定义的范围之外的变量。

即使导出了func，也不可能为其提供适当的单元测试，即在一个测试中测试func，然后在另一个测试中测试一个依赖于func（MyComponent）的单元func 被嘲笑/监视。 func 在模块中被引用，它的调用不能被窥探或存根。

为了完全可测试，func 需要是任一类方法，如果 func 和 MyComponent 相关，则这是有意义的。或者将func 移动到另一个模块。在这种情况下，可以模拟模块，或者如 this answer 中所述，由于 ES 模块的工作方式，func 导入可以在模块 * 导入上进行模拟/监视。

【讨论】：

同意将 func 作为类方法，这是有道理的，但我试图将逻辑保留在组件之外，结果证明这是测试头痛
是的。另一方面，如果它没有严格地绑定到当前类并且可以在类之外使用，那么它不应该成为这个模块的一部分，这就是常见的可测试性问题所暗示的。
您可以通过解构您的导入来导出函数并直接对其进行测试。我在下面提供了一个示例。
@dysfunc 你不能通过这种方式窥探或模拟func。顺便说一句，它不再可以称为“私人”，因为它不是。
这也不对。您可以使用* 导入模块，它输出模块对象import * as MyComponent from './myComponent';，然后您可以使用spy 或stub 那里的方法someLib.spy(MyComponent, 'func')

【解决方案2】：

很难从私有方法的单元测试中获得任何价值。

你为什么想要那个？

增加测试覆盖率 KPI。但是一旦私有方法被公共调用 - 它们无论如何都会被考虑在内。
为了确保一切正常......但是对私有方法进行测试可能会导致：

一个。测试被破坏，而作为系统一部分的组件工作正常（例如，私有方法已被更改、重命名或删除......但没有对其进行测试） - 假阴性

b.私有方法的测试很好，但是组件被破坏了（比如说，私有方法需要被调用但它不是） - 误报

【讨论】：

这真的很有帮助。感谢您的澄清！
至于，没关系，当您对代码进行重大更改时，测试失败是您所期望的。至于b，这是通过监视函数来解决的，如果函数驻留在同一模块中并且不是方法，则这是不可能的。
我不同意这一点。直接测试私有方法有很多价值，尤其是当它们执行转换或包含大量逻辑时。为什么不确保涵盖所有私有方法用例和边缘案例？您必须为组件编写测试，这些测试将涵盖私有函数的大多数用例，但代码库的新手往往会滥用该函数，而测试没有考虑到这一点，因此它不会被注意到。比用狭隘的眼光写测试要彻底。
@dysfunc 所以有一段复杂的逻辑。它没有暴露。所以它不能在其他地方重复使用。所以它要么非常独特，仅在单个地方和特定情况下才有意义，要么复杂而不复杂，应该分解以实现可重用性。
如果该函数是实用程序/通用函数，则应将其移至其自己的模块并独立/彻底测试，但为什么不测试给定模块的所有内容呢？如果该类依赖于该函数来执行某些操作以正常运行，则应对其进行整体测试