node.js测试: 如何利用import / require语法打桩测试指定函数/ 类方法

node.js测试: 如何利用import / require语法打桩测试指定函数/ 类方法

ES6: Use of “import { property } from ‘module'” is Not a Great Plan – Ex Ratione
https://www.exratione.com/2015/12/es6-use-of-import-property-from-module-is-not-a-great-plan/

ES6: Use of "import { property } from 'module'" is Not a Great Plan

By ReasonDecember 18th, 2015Permalink

The Javascript ES6 standard brings a new syntax for declaring imports from other modules
and exports from the present modules. Here I'll argue that some of that syntax, specifically the ability to import one or more named properties from a module, is overused in the community and causes more trouble than it is worth when writing ES6 Javascript
applications. The ES6 syntax for import and export is noted below in brief:

Import and Export in Node.js and ES5
There are both obvious and subtle differences between the ES6 syntax listed above and the module frameworks in common use for ES5 Javascript ecosystems, such as Node.js. In the Node.js ES5 world, every module exports a default object unless that is replaced,
and an entirely empty module still exports an object with no properties. There is only one way to import a module, and that imports either the default export object, or whatever that object was explicitly replaced with. So:

exampleObject.js:

exampleString.js:

exampleEmptyModule.js:

exampleImports.js:

Import and Export in ES6
In ES6 modules there is no one straightforward analogy to module.exports in Node.js ES5, though it can be recreated by some combinations of export and import definitions:

example.es6.js:

exampleProperty.es6.js:

exampleEmptyModule.es6.js:

exampleImports.es6.js:

The Syntax "import { x } from 'y'" is Popular
If you look at the ES6 ecosystem, you'll see that the use of property import is popular. I'm seeing a lot of it now that I'm working with modules relating to React,
both in documentation and code. In Redux, for example, important functions are exported as properties in modules with no default export, and the documentation provides
examples like the following:

This could equally be written in the following way:

It isn't, however, and it doesn't take very much work on a real application to start to see that using property import is a problem. Why is it a problem? Because it impedes the use of mocking and stubbing in tests, such as the functionality provided by frameworks
like Sinon. It is somewhere between very hard and impossible to write sufficient unit tests without the ability to stub and spy on function calls. It requires an
annoying amount of additional boilerplate code to make that possible for property importing, as the following small examples illustrate.

Stubbing in ES5 Javascript Testing
Stubbing a function in Javascript requires the function to be bound to a context, any context, that is in scope for both the test code and the code being tested. In a sane world this context is provided by the module. For example, in ES5 Node.js:

lib/example.js

lib/invokeExample.js

test/lib/invokeExample.spec.js

The thing to avoid doing in ES5 is the following, overriding module.exports with a function. All too many people do this and it is inconsiderate, as any module using that code must then take extra steps to be usefully unit tested:

lib/example.js

lib/invokeExample.js

test/lib/invokeExample.spec.js

Stubbing in ES6
In ES6 using "import { x } from 'y'" is analogous to overwriting module.exports with a function in ES5. The result is that an imported function is encapsulated in the module and cannot be stubbed in unit tests without writing more boilerplate code that would
otherwise have been the case. See this example:

lib/example.es6.js

lib/invokeExample.es6.js

test/lib/invokeExample.spec.es6.js

This boilerplate is unnecessary; it goes away if a sensible import statement is used, as in the following example:

lib/example.es6.js

lib/invokeExample.es6.js

test/lib/invokeExample.spec.es6.js

In Short, Avoid the Use of "import { x } from 'y'"
The bottom line is that "import { x } from 'y'" should be largely or completely absent from ES6 code in order to make the code both clean and testable. Yes, it's the new new thing, but no, it doesn't make life any better.