blocks|key|922678|text|您必须构建您的单元测试套件，以便首先测试最低级别的模块，然后再测试需要模块的较高级别的模块。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|922679|您还必须假设任何第三方代码和node.js本身都经过了良好的测试。|922680|我假设您会在不久的将来看到覆盖global.require的模拟框架的出现|offset|length|style|CODE|922681|如果你真的必须注入一个mock，你可以修改你的代码来公开模块化的作用域。|922682|//+underTest.js
var+innerLib+=+require('./path/to/innerLib');

function+underTest()+{
++++return+innerLib.toCrazyCrap();
}

module.exports+=+underTest;
module.exports.__module+=+module;

//+test.js
function+test()+{
++++var+underTest+=+require("underTest");
++++underTest.__module.innerLib+=+{
++++++++toCrazyCrap:+function()+{+return+true;+}
++++};
++++assert.ok(underTest());
}|code-block|syntax|javascript|922683|需要注意的是，这会将.__module暴露到您的应用程序接口中，并且任何代码都可以访问模块化作用域，这是他们自己的危险。|922684|entityMap^0|0|0|F|E|0|0|0|A|9|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|10|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|11|8|@$F|12|G|13|H|I]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

You can't. You have to build up your unit test suite so that the lowest modules are tested first and that the higher level modules that require modules are tested afterwards.

You also have to assume that any 3rd party code and node.js itself is well tested. 

I presume you'll see mocking frameworks arrive in the near future that overwrite <code>global.require</code>

If you really must inject a mock you can change your code to expose modular scope.

<pre><code>// underTest.js
var innerLib = require('./path/to/innerLib');

function underTest() {
 return innerLib.toCrazyCrap();
}

module.exports = underTest;
module.exports.__module = module;

// test.js
function test() {
 var underTest = require("underTest");
 underTest.__module.innerLib = {
 toCrazyCrap: function() { return true; }
 };
 assert.ok(underTest());
}
</code></pre>

Be warned this exposes <code>.__module</code> into your API and any code can access modular scope at their own danger.

blocks|key|706238|text|在这种情况下，更好的选择是模拟返回的模块的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|706239|不管是好是坏，大多数node.js模块都是单例的；需要()相同模块的两段代码会得到对该模块的相同引用。|706240|您可以利用这一点，并使用诸如sinon之类的东西来模拟所需的项。mocha测试如下：|offset|length|706241|//+in+your+testfile
var+innerLib++=+require('./path/to/innerLib');
var+underTest+=+require('./path/to/underTest');
var+sinon+++++=+require('sinon');

describe("underTest",+function()+{
++it("does+something",+function()+{
++++sinon.stub(innerLib,+'toCrazyCrap').callsFake(function()+{
++++++//+whatever+you+would+like+innerLib.toCrazyCrap+to+do+under+test
++++});

++++underTest();

++++sinon.assert.calledOnce(innerLib.toCrazyCrap);+//+sinon+assertion

++++innerLib.toCrazyCrap.restore();+//+restore+original+functionality
++});
});|code-block|syntax|javascript|706242|Sinon具有用于进行断言的良好integration+with+chai，并且我向integrate+sinon+with+mocha编写了一个模块以允许更容易地进行间谍/存根清理(以避免测试污染)。|706243|注意，不能以同样的方式模拟underTest，因为underTest只返回一个函数。|706244|另一种选择是使用Jest+mock。在their+page上跟进|706245|entityMap|0|LINK|mutability|MUTABLE|url|http://sinonjs.org/|1|http://visionmedia.github.io/mocha/|2|https://github.com/domenic/sinon-chai|3|https://github.com/elliotf/mocha-sinon|4|https://jestjs.io/docs/en/manual-mocks^0|0|0|E|5|0|W|5|1|0|0|G|L|2|16|Q|3|0|0|J|A|4|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@$F|1B|G|1C|1|1D]|$F|1E|G|1F|1|1G]]|A|$]]|$1|H|3|I|5|J|7|1H|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1I|8|@]|9|@$F|1J|G|1K|1|1L]|$F|1M|G|1N|1|1O]]|A|$]]|$1|O|3|P|5|6|7|1P|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Q|8|@]|9|@$F|1R|G|1S|1|1T]]|A|$]]|$1|S|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]|10|$5|V|W|X|A|$Y|11]]|12|$5|V|W|X|A|$Y|13]]|14|$5|V|W|X|A|$Y|15]]|16|$5|V|W|X|A|$Y|17]]]]

A better option in this case is to mock methods of the module that gets returned.

For better or worse, most node.js modules are singletons; two pieces of code that require() the same module get the same reference to that module.

You can leverage this and use something like <a href="http://sinonjs.org/" rel="noreferrer">sinon</a> to mock out items that are required. <a href="http://visionmedia.github.io/mocha/" rel="noreferrer">mocha</a> test follows:

<pre><code>// in your testfile
var innerLib = require('./path/to/innerLib');
var underTest = require('./path/to/underTest');
var sinon = require('sinon');

describe("underTest", function() {
 it("does something", function() {
 sinon.stub(innerLib, 'toCrazyCrap').callsFake(function() {
 // whatever you would like innerLib.toCrazyCrap to do under test
 });

 underTest();

 sinon.assert.calledOnce(innerLib.toCrazyCrap); // sinon assertion

 innerLib.toCrazyCrap.restore(); // restore original functionality
 });
});
</code></pre>

Sinon has good <a href="https://github.com/domenic/sinon-chai" rel="noreferrer">integration with chai</a> for making assertions, and I wrote a module to <a href="https://github.com/elliotf/mocha-sinon" rel="noreferrer">integrate sinon with mocha</a> to allow for easier spy/stub cleanup (to avoid test pollution.)

Note that underTest cannot be mocked in the same way, as underTest returns only a function.

Another option is to use Jest mocks. Follow up on <a href="https://jestjs.io/docs/en/manual-mocks" rel="noreferrer">their page</a>

blocks|key|706268|text|我使用mock-require。确保在对要测试的模块执行require操作之前定义了模拟。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|706269|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/boblauer/mock-require^0|S|7|3|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

I use <a href="https://github.com/boblauer/mock-require" rel="noreferrer">mock-require</a>. Make sure you define your mocks before you <code>require</code> the module to be tested.

blocks|key|922786|text|您可以使用mockery库：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|922787|describe+'UnderTest',+->
++before+->
++++mockery.enable(+warnOnUnregistered:+false+)
++++mockery.registerMock('./path/to/innerLib',+{+doComplexStuff:+->+'Complex+result'+})
++++@underTest+=+require('./path/to/underTest')

++it+'should+compute+complex+value',+->
++++expect(@underTest()).to.eq+'Complex+result'|code-block|syntax|javascript|922788|entityMap|0|LINK|mutability|MUTABLE|url|https://www.npmjs.com/package/mockery^0|5|7|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

You can use <a href="https://www.npmjs.com/package/mockery" rel="nofollow noreferrer">mockery</a> library:

<pre><code>describe 'UnderTest', -&gt;
 before -&gt;
 mockery.enable( warnOnUnregistered: false )
 mockery.registerMock('./path/to/innerLib', { doComplexStuff: -&gt; 'Complex result' })
 @underTest = require('./path/to/underTest')

 it 'should compute complex value', -&gt;
 expect(@underTest()).to.eq 'Complex result'
</code></pre>

blocks|key|922838|text|嘲笑require对我来说就像是一个讨厌的黑客。我个人会尽量避免这种情况，并重构代码以使其更具可测试性。有多种方法来处理依赖关系。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|922839|1)将依赖项作为参数传递|922840|function+underTest(innerLib)+{
++++return+innerLib.doComplexStuff();
}|code-block|syntax|javascript|922841|这将使代码具有普遍的可测试性。缺点是您需要传递依赖项，这会使代码看起来更复杂。|922842|2)将模块实现为类，然后使用类方法/属性获取依赖关系|922843|(这是一个人为的例子，其中类的使用是不合理的，但它传达了这个想法)+(ES6例子)|922844|const+innerLib+=+require('./path/to/innerLib')

class+underTestClass+{
++++getInnerLib+()+{
++++++++return+innerLib
++++}

++++underTestMethod+()+{
++++++++return+this.getInnerLib().doComplexStuff()
++++}
}|922845|现在，您可以轻松地使用存根getInnerLib方法来测试代码。代码变得更加冗长，但也更容易测试。|922846|entityMap^0|2|7|0|0|0|0|0|0|0|D|B|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|15|8|@]|D|@]|E|$]]|$1|S|3|T|5|J|7|16|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|X|$]]

Mocking <code>require</code> feels like a nasty hack to me. I would personally try to avoid it and refactor the code to make it more testable.
There are various approaches to handle dependencies.

1) pass dependencies as arguments

<pre><code>function underTest(innerLib) {
 return innerLib.doComplexStuff();
}
</code></pre>

This will make the code universally testable. The downside is that you need to pass dependencies around, which can make the code look more complicated.

2) implement the module as a class, then use class methods/ properties to obtain dependencies

(This is a contrived example, where class usage is not reasonable, but it conveys the idea)
(ES6 example)

<pre><code>const innerLib = require('./path/to/innerLib')

class underTestClass {
 getInnerLib () {
 return innerLib
 }

 underTestMethod () {
 return this.getInnerLib().doComplexStuff()
 }
}
</code></pre>

Now you can easily stub <code>getInnerLib</code> method to test your code. 
The code becomes more verbose, but also easier to test.

This is a trivial example that illustrates the crux of my problem:

<pre><code>var innerLib = require('./path/to/innerLib');

function underTest() {
 return innerLib.doComplexStuff();
}

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

I am trying to write a unit test for this code. How can I mock out the requirement for the <code>innerLib</code> without mocking out the <code>require</code> function entirely?

So this is me trying to mock out the global <code>require</code> and finding out that it won’t work even to do that:

<pre><code>var path = require('path'),
 vm = require('vm'),
 fs = require('fs'),
 indexPath = path.join(__dirname, './underTest');

var globalRequire = require;

require = function(name) {
 console.log('require: ' + name);
 switch(name) {
 case 'connect':
 case indexPath:
 return globalRequire(name);
 break;
 }
};
</code></pre>

The problem is that the <code>require</code> function inside the <code>underTest.js</code> file has actually not been mocked out. It still points to the global <code>require</code> function. So it seems that I can only mock out the <code>require</code> function within the same file I’m doing the mocking in. If I use the global <code>require</code> to include anything, even after I’ve overridden the local copy, the files being required will still have the global <code>require</code> reference.

How to unit test a Node.js module that requires other modules and how to mock the global require function?

单元测试

这是一个微不足道的例子，说明了我的问题的症结所在：var innerLib = require('./path/to/innerLib');function underTest() {    return innerLib.doComplexStuff();}module.exports = underTest;我正在...

问如何对需要其他模块的Node.js模块进行单元测试，以及如何模拟全局请求函数？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何对需要其他模块的Node.js模块进行单元测试，以及如何模拟全局请求函数？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何对需要其他模块的Node.js模块进行单元测试，以及如何模拟全局请求函数？
EN