blocks|key|163284|text|如果该函数不是由模块导出的，则无法由模块外部的测试代码调用该函数。这是由于JavaScript的工作方式，而Mocha本身无法绕过这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|163285|在少数情况下，我确定测试私有函数是正确的，我设置了一些环境变量，我的模块会检查这些变量，以确定它是否在测试设置中运行。如果它在测试设置中运行，那么它将导出额外的函数，然后我可以在测试期间调用这些函数。|163286|“环境”这个词在这里用得不够严谨。这可能意味着检查process.env或其他可以与“你现在正在被测试”模块通信的东西。我不得不这样做的实例是在RequireJS环境中，为此我使用了module.config。|offset|length|style|CODE|163287|entityMap|0|LINK|mutability|MUTABLE|url|http://www.requirejs.org/^0|0|0|P|B|2J|D|20|9|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@$F|U|G|V|H|I]|$F|W|G|X|H|I]]|9|@$F|Y|G|Z|1|10]]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

If the function is not exported by the module, it cannot be called by test code outside the module. That's due to how JavaScript works, and Mocha cannot by itself circumvent this.
In the few instances where I determined that testing a private function is the right thing to do, I've set some environment variable that my module checks to determine whether it is running in a test setup or not. If it runs in the test setup, then it exports additional functions that I can then call during testing.
The word &quot;environment&quot; is loosely used here. It might mean checking <code>process.env</code> or something else that can communicate to the module &quot;you're being tested now&quot;. The instances where I've had to do this were in a <a href="http://www.requirejs.org/" rel="noreferrer">RequireJS</a> environment, and I've used <code>module.config</code> for this purpose.

blocks|key|163319|text|为此，我制作了一个npm包，您可能会发现它很有用：require-from|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|163320|基本上，您可以通过以下方式公开非公共方法：|163321|module.testExports+=+{
++++private_foobar1:+private_foobar1,
++++private_foobar2:+private_foobar2,
++++...
}|code-block|syntax|javascript|163322|注意：testExports可以是您想要的任何有效名称，当然exports除外。|style|CODE|163323|并且来自另一个模块：|163324|var+requireFrom+=+require('require-from');
var+private_foobar1+=+requireFrom('testExports',+'./path-to-module').private_foobar1;|163325|entityMap|0|LINK|mutability|MUTABLE|url|https://www.npmjs.org/package/require-from^0|P|C|0|0|0|0|3|B|U|7|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|16|8|@$A|17|B|18|M|N]|$A|19|B|1A|M|N]]|9|@]|C|$]]|$1|O|3|P|5|6|7|1B|8|@]|9|@]|C|$]]|$1|Q|3|R|5|H|7|1C|8|@]|9|@]|C|$I|J]]|$1|S|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]]]

I made an npm package for this purpose that you might find useful: <a href="https://www.npmjs.org/package/require-from" rel="nofollow noreferrer">require-from</a>
Basically, you expose non-public methods by:
<pre><code>module.testExports = {
 private_foobar1: private_foobar1,
 private_foobar2: private_foobar2,
 ...
}
</code></pre>
Note: <code>testExports</code> can be any valid name you want, except <code>exports</code> of course.
And from another module:
<pre><code>var requireFrom = require('require-from');
var private_foobar1 = requireFrom('testExports', './path-to-module').private_foobar1;
</code></pre>

blocks|key|161996|text|如果你想保持简单，只需导出私有成员，但通过一些约定与公共API明确分开，例如用_作为它们的前缀或将它们嵌套在单个私有对象下。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|161997|var+privateWorker+=+function()+{
++++return+1
}

var+doSomething+=+function()+{
++++return+privateWorker()
}

module.exports+=+{
++++doSomething:+doSomething,
++++_privateWorker:+privateWorker
}|code-block|syntax|javascript|161998|entityMap^0|13|1|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

If you'd prefer to keep it simple, just export the private members as well, but clearly separated from the public API with some convention, e.g. prefix them with an <code>_</code> or nest them under a single private object.

<pre><code>var privateWorker = function() {
 return 1
}

var doSomething = function() {
 return privateWorker()
}

module.exports = {
 doSomething: doSomething,
 _privateWorker: privateWorker
}
</code></pre>

blocks|key|2965733|text|谷歌工程师菲利普·沃尔顿在他的博客上解释了Here+is+a+really+good+workflow+to+test+your+private+methods。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2965734|原则|2965735|正常编写您的代码，并将您的私有方法绑定到单独代码块中的对象，并用注释标记它(+example)|2965736|Surround+|unordered-list-item|2965737|2965738|+_+|style|CODE|2965739|2965740|2965741|然后使用一个构建任务或您自己的构建系统(例如grunt+strip+code)来为生产构建剥离这个块。|2965742|您的测试构建可以访问您的私有API，而您的生产构建则不能。|2965743|代码段|2965744|按如下方式编写代码：|2965745|var+myModule+=+(function()+{

++function+foo()+{
++++//+Private+function+`foo`+inside+closure
++++return+"foo"
++}

++var+api+=+{
++++bar:+function()+{
++++++//+Public+function+`bar`+returned+from+closure
++++++return+"bar"
++++}
++}

++/*+test-code+*/
++api._foo+=+foo
++/*+end-test-code+*/

++return+api
}())|code-block|syntax|javascript|2965746|您的Grunt任务如下所示：|2965747|grunt.registerTask("test",+[
++"concat",
++"jshint",
++"jasmine"
])
grunt.registerTask("deploy",+[
++"concat",
++"strip-code",
++"jshint",
++"uglify"
])|2965748|更深层次|2965749|In+a+later+article，它解释了“测试私有方法”的“原因”|2965750|entityMap|0|LINK|mutability|MUTABLE|url|http://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/|1|https://en.wikipedia.org/wiki/Grunt_(software)|2|http://philipwalton.com/articles/why-i-test-private-functions-in-javascript/^0|L|1N|0|0|0|0|0|0|1|1|0|0|0|0|0|0|0|0|2|5|1|0|0|0|0|I|2|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@$A|1P|B|1Q|1|1R]]|C|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1T|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1U|8|@]|9|@]|C|$]]|$1|K|3|-4|5|J|7|1V|8|@]|9|@]|C|$]]|$1|L|3|M|5|J|7|1W|8|@$A|1X|B|1Y|N|O]]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|20|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|21|8|@]|9|@]|C|$]]|$1|T|3|U|5|6|7|22|8|@]|9|@]|C|$]]|$1|V|3|W|5|6|7|23|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|24|8|@]|9|@]|C|$]]|$1|Z|3|10|5|11|7|25|8|@]|9|@]|C|$12|13]]|$1|14|3|15|5|6|7|26|8|@]|9|@$A|27|B|28|1|29]]|C|$]]|$1|16|3|17|5|11|7|2A|8|@]|9|@]|C|$12|13]]|$1|18|3|19|5|6|7|2B|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|6|7|2C|8|@]|9|@$A|2D|B|2E|1|2F]]|C|$]]|$1|1C|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]]|1D|$1E|$5|1F|1G|1H|C|$1I|1J]]|1K|$5|1F|1G|1H|C|$1I|1L]]|1M|$5|1F|1G|1H|C|$1I|1N]]]]

<a href="http://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/" rel="nofollow noreferrer">Here is a really good workflow to test your private methods</a> explained by Philip Walton, a Google engineer on his blog.
<h1>Principle</h1>
<ul>
<li>Write your code normally</li>
<li>Bind your private methods to the object in a separate code block, and mark it by an <code>_</code> (for example)</li>
<li>Surround that code block by start and end comments</li>
</ul>
Then use a build task or your own build system (for example grunt-strip-code) to strip this block for production builds.
Your tests builds have access to your private API, and your production builds have not.
<h1>Snippet</h1>
Write your code as this:
<pre><code>var myModule = (function() {

 function foo() {
 // Private function `foo` inside closure
 return &quot;foo&quot;
 }

 var api = {
 bar: function() {
 // Public function `bar` returned from closure
 return &quot;bar&quot;
 }
 }

 /* test-code */
 api._foo = foo
 /* end-test-code */

 return api
}())
</code></pre>
And your <a href="https://en.wikipedia.org/wiki/Grunt_(software)" rel="nofollow noreferrer">Grunt</a> tasks like this:
<pre><code>grunt.registerTask(&quot;test&quot;, [
 &quot;concat&quot;,
 &quot;jshint&quot;,
 &quot;jasmine&quot;
])
grunt.registerTask(&quot;deploy&quot;, [
 &quot;concat&quot;,
 &quot;strip-code&quot;,
 &quot;jshint&quot;,
 &quot;uglify&quot;
])
</code></pre>
<h1>Deeper</h1>
<a href="http://philipwalton.com/articles/why-i-test-private-functions-in-javascript/" rel="nofollow noreferrer">In a later article</a>, it explains the &quot;why&quot; of &quot;testing private methods&quot;

blocks|key|162040|text|查看rewire模块。它允许您获取(和操作)模块中的私有变量和函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|162041|因此，在您的示例中，用法类似于：|162042|var+rewire+=+require('rewire'),
++++foobar+=+rewire('./foobar');+//+Bring+your+module+in+with+rewire

describe("private_foobar1",+function()+{

++++//+Use+the+special+'__get__'+accessor+to+get+your+private+function.
++++var+private_foobar1+=+foobar.__get__('private_foobar1');

++++it("should+do+stuff",+function(done)+{
++++++++var+stuff+=+private_foobar1(filter);
++++++++should(stuff).be.ok;
++++++++should(stuff).....|code-block|syntax|javascript|162043|entityMap|0|LINK|mutability|MUTABLE|url|https://www.npmjs.com/package/rewire^0|2|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|C|$I|J]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

Check out the <a href="https://www.npmjs.com/package/rewire">rewire</a> module. It allows you to get (and manipulate) private variables and functions within a module.

So in your case the usage would be something like:

<pre><code>var rewire = require('rewire'),
 foobar = rewire('./foobar'); // Bring your module in with rewire

describe("private_foobar1", function() {

 // Use the special '__get__' accessor to get your private function.
 var private_foobar1 = foobar.__get__('private_foobar1');

 it("should do stuff", function(done) {
 var stuff = private_foobar1(filter);
 should(stuff).be.ok;
 should(stuff).....
</code></pre>

blocks|key|2753473|text|我跟踪了barwin's+answer，并检查了如何使用rewire模块进行单元测试。我可以确认这个解决方案是简单有效的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2753474|该模块应该分为两个部分-一个公共模块和一个私有模块。对于公共函数，你可以用标准的方式来实现：|2753475|const+{+public_foobar3+}+=+require('./foobar');|code-block|syntax|javascript|2753476|对于私有作用域：|2753477|const+privateFoobar+=+require('rewire')('./foobar');
const+private_foobar1+=+privateFoobar+.__get__('private_foobar1');
const+private_foobar2+=+privateFoobar+.__get__('private_foobar2');|2753478|为了更多地了解这个主题，我创建了一个完整模块测试的工作示例，测试包括私有和公共范围。|2753479|有关更多信息，我建议您查看详细描述该主题的文章()。它包括代码示例。|2753480|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/22097603/unit-testing-of-private-functions-with-mocha-and-node-js/31462773#31462773^0|S|6|4|F|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@$9|15|A|16|1|17]]|E|$]]|$1|F|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|19|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1A|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|1B|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1C|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1D|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11]]]]

I followed <a href="https://stackoverflow.com/questions/22097603/unit-testing-of-private-functions-with-mocha-and-node-js/31462773#31462773">barwin's answer</a> and checked how unit tests can be made with rewire module. I can confirm that this solution simply works.
The module should be required in two parts - a public one and a private one. For public functions you can do that in standard way:
<pre><code>const { public_foobar3 } = require('./foobar');
</code></pre>
For private scope:
<pre><code>const privateFoobar = require('rewire')('./foobar');
const private_foobar1 = privateFoobar .__get__('private_foobar1');
const private_foobar2 = privateFoobar .__get__('private_foobar2');
</code></pre>
In order to know more about the subject, I created a working example with full module testing, testing includes private and public scope.
For further information I encourage you to check the article (<a href="https://medium.com/@macsikora/how-to-test-private-functions-of-es6-module-fb8c1345b25f" rel="nofollow noreferrer">How to test private functions of a CommonJS module</a>) fully describing the subject. It includes code samples.

blocks|key|2965875|text|我已经添加了一个额外的函数，我将其命名为内部()，并从那里返回所有私有函数。然后导出此内部()函数。示例：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2965876|function+Internal+()+{
++return+{+Private_Function1,+Private_Function2,+Private_Function2}
}

//+Exports+--------------------------
module.exports+=+{+PublicFunction1,+PublicFunction2,+Internal+}|code-block|syntax|javascript|2965877|您可以像这样调用内部函数：|2965878|let+test+=+require('.....')
test.Internal().Private_Function1()|2965879|我最喜欢这个解决方案，因为：|2965880|2965881|始终只导出一个内部函数()。这个内部functions.|unordered-list-item|2965882|It+()+implement|2965883|Low函数总是用来测试私有的对生产代码的影响很简单(只有一个额外的函数)|2965884|2965885|entityMap^0|K|4|17|4|0|0|0|0|0|0|B|2|0|0|E|M|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|16|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|17|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|18|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|19|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|R|3|S|5|T|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|U|3|V|5|T|7|1E|8|@]|D|@]|E|$]]|$1|W|3|X|5|T|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]]|10|$]]

I have added an extra function that I name Internal() and return all private functions from there. This Internal() function is then exported. Example:

<pre><code>function Internal () {
 return { Private_Function1, Private_Function2, Private_Function2}
}

// Exports --------------------------
module.exports = { PublicFunction1, PublicFunction2, Internal }
</code></pre>

You can call the internal functions like this:

<pre><code>let test = require('.....')
test.Internal().Private_Function1()
</code></pre>

I like this solution best because:

<ul>
<li>only one function Internal() is always exported. This Internal() function is always used to test private functions.</li>
<li>It is simple to implement</li>
<li>Low impact on the production code (only one extra function) </li>
</ul>

blocks|key|2965891|text|我知道这不一定是您正在寻找的答案，但我发现，大多数时候，如果一个私有函数值得测试，那么它就值得放在自己的文件中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2965892|例如，不是将私有方法和公共方法放在同一个文件中，而是像这样...|2965893|src/thing/PublicInterface.js|offset|length|style|BOLD|2965894|function+helper1+(x)+{
++++return+2+*+x;
}

function+helper2+(x)+{
++++return+3+*+x;
}

export+function+publicMethod1(x)+{
++++return+helper1(x);
}

export+function+publicMethod2(x)+{
++++return+helper1(x)+%2B+helper2(x);
}|code-block|syntax|javascript|2965895|...you将其拆分如下：|2965896|2965897|import+{helper1}+from+'./internal/helper1.js';
import+{helper2}+from+'./internal/helper2.js';

export+function+publicMethod1(x)+{
++++return+helper1(x);
}

export+function+publicMethod2(x)+{
++++return+helper1(x)+%2B+helper2(x);
}|2965898|src/thing/internal/helper1.js|2965899|export+function+helper1+(x)+{
++++return+2+*+x;
}|2965900|src/thing/internal/helper2.js|2965901|export+function+helper2+(x)+{
++++return+3+*+x;
}|2965902|这样，您就可以轻松地按原样测试helper1和helper2，而无需使用Rewire和其他“魔术”(我发现，它们在调试时或在您尝试迁移到TypeScript时都有自己的痛点，更不用说新同事的可理解性更差了)。并且它们位于名为internal或类似的子文件夹中，有助于避免意外地在非预期的地方使用它们。|CODE|2965903|2965904|附言：“私有”方法的另一个常见问题是，如果你想测试publicMethod1和publicMethod2并模拟助手，你通常需要像Rewire这样的东西来做这些事情。但是，如果它们位于不同的文件中，则可以使用Proxyquire完成此操作，与Rewire不同，它不需要对构建过程进行任何更改，易于阅读和调试，甚至可以与TypeScript一起很好地工作。|2965905|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/thlorenz/proxyquire^0|0|0|0|S|0|0|0|0|S|0|0|0|T|0|0|0|T|0|0|F|7|N|7|34|8|0|0|P|D|13|D|2V|A|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1H|8|@$F|1I|G|1J|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|1K|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1L|8|@]|9|@]|A|$]]|$1|Q|3|E|5|6|7|1M|8|@$F|1N|G|1O|H|I]]|9|@]|A|$]]|$1|R|3|S|5|L|7|1P|8|@]|9|@]|A|$M|N]]|$1|T|3|U|5|6|7|1Q|8|@$F|1R|G|1S|H|I]]|9|@]|A|$]]|$1|V|3|W|5|L|7|1T|8|@]|9|@]|A|$M|N]]|$1|X|3|Y|5|6|7|1U|8|@$F|1V|G|1W|H|I]]|9|@]|A|$]]|$1|Z|3|10|5|L|7|1X|8|@]|9|@]|A|$M|N]]|$1|11|3|12|5|6|7|1Y|8|@$F|1Z|G|20|H|13]|$F|21|G|22|H|13]|$F|23|G|24|H|13]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|26|8|@$F|27|G|28|H|13]|$F|29|G|2A|H|13]]|9|@$F|2B|G|2C|1|2D]]|A|$]]|$1|17|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]]|18|$19|$5|1A|1B|1C|A|$1D|1E]]]]

I know that this is not necessarily the answer you are looking for, but I have found that most of the time if a private function is worth testing, it's worth being in its own file.
E.g., instead of having private methods in the same file as the public ones, like this...
src/thing/PublicInterface.js
<pre><code>
function helper1 (x) {
 return 2 * x;
}

function helper2 (x) {
 return 3 * x;
}

export function publicMethod1(x) {
 return helper1(x);
}

export function publicMethod2(x) {
 return helper1(x) + helper2(x);
}
</code></pre>
...you split it up like this:
src/thing/PublicInterface.js
<pre><code>import {helper1} from './internal/helper1.js';
import {helper2} from './internal/helper2.js';

export function publicMethod1(x) {
 return helper1(x);
}

export function publicMethod2(x) {
 return helper1(x) + helper2(x);
}
</code></pre>
src/thing/internal/helper1.js
<pre><code>export function helper1 (x) {
 return 2 * x;
}
</code></pre>
src/thing/internal/helper2.js
<pre><code>export function helper2 (x) {
 return 3 * x;
}
</code></pre>
That way, you can easily test <code>helper1</code> and <code>helper2</code> as-is, without using Rewire and other &quot;magic&quot; (which, I have found, have their own pain points while debugging, or when you try to make your move towards TypeScript, not to mention poorer understandability for new colleagues). And them being in a sub-folder called <code>internal</code>, or something like that, will help avoiding accidental usage of them in unintended places.
<hr />
P.S.: Another common issue with &quot;private&quot; methods is that if you want to test <code>publicMethod1</code> and <code>publicMethod2</code> and mock the helpers, again, you normally need something like Rewire to do that. However, if they are in separate files, you can use <a href="https://github.com/thlorenz/proxyquire" rel="nofollow noreferrer">Proxyquire</a> to do it, which, unlike Rewire, doesn't need any changes to your build process, is easy to read and to debug, and works well even with TypeScript.

blocks|key|2965924|text|为了使私有方法可用于测试，我这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2965925|const+_myPrivateMethod:+()+=>+{};

const+methods+=+{
++++myPublicMethod1:+()+=>+{},
++++myPublicMethod2:+()+=>+{},
}

if+(process.env.NODE_ENV+===+'test')+{
++++methods._myPrivateMethod+=+_myPrivateMethod;
}

module.exports+=+methods;|code-block|syntax|javascript|2965926|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

To make private methods available for testing, I do this:

<pre><code>const _myPrivateMethod: () =&gt; {};

const methods = {
 myPublicMethod1: () =&gt; {},
 myPublicMethod2: () =&gt; {},
}

if (process.env.NODE_ENV === 'test') {
 methods._myPrivateMethod = _myPrivateMethod;
}

module.exports = methods;
</code></pre>

I am using <a href="https://en.wikipedia.org/wiki/Mocha_(JavaScript_framework)" rel="noreferrer">Mocha</a> in order to unit test an application written for Node.js.
I wonder if it's possible to unit test functions that have not been exported in a module.
Example:
I have a lot of functions defined like this in <code>foobar.js</code>:
<pre><code>function private_foobar1(){
 ...
}

function private_foobar2(){
 ...
}
</code></pre>

And a few functions exported as public:
<pre><code>exports.public_foobar3 = function(){
 ...
}
</code></pre>
The test case is structured as follows:
<pre><code>describe(&quot;private_foobar1&quot;, function() {
 it(&quot;should do stuff&quot;, function(done) {
 var stuff = foobar.private_foobar1(filter);
 should(stuff).be.ok;
 should(stuff).....
</code></pre>
Obviously this does not work, since <code>private_foobar1</code> is not exported.
What is the correct way to unit-test private methods? Does Mocha have some built-in methods for doing that?

Unit testing of private functions with Mocha and Node.js

我使用对为Node.js编写的应用程序进行单元测试。我想知道是否有可能对模块中未导出的函数进行单元测试。示例：我在foobar.js中定义了很多这样的函数function private_foobar1(){    ...}function private_foobar2(){    ...}以及一些导出为public...

问使用Mocha和Node.js对私有函数进行单元测试
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用Mocha和Node.js对私有函数进行单元测试EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用Mocha和Node.js对私有函数进行单元测试
EN