TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How to Test Private Functions in JS Modules

15 点作者 jonahkagan将近 11 年前

7 条评论

daniellmb将近 11 年前
Using the NODE_ENV is nice simple solution but when you need more there is a great dependency injection module called rewire that adds a special setter and getter to modules so you can modify their behavior such as: inject mocks for other modules or globals like process, leak private variables override variables within the module.<p>This is especially nice because you don&#x27;t need to add any special if statements to the module code you just load your module under test using rewire instead of require.<p>&#x2F;&#x2F; file: test-stats-rewire.js<p>var rewire = require(&#x27;rewire&#x27;);<p>var assert = require(&#x27;assert&#x27;);<p>var stats = rewire(&#x27;.&#x2F;stats&#x27;);<p>&#x2F;&#x2F; leak private method sum for testing<p>var sum = stats.__get__(&#x27;sum&#x27;);<p>assert.equal(sum([1]), 1);<p>assert.equal(sum([1, 2, 3]), 6);
joebadmo将近 11 年前
If you really want to buy into the module pattern, it seems like anything that&#x27;s enough of a unit that you&#x27;d want to test could be in its own module.<p>In the example given, the sum function could be its own module that you require into the stats module. That way you could test them independently, and the stats module could simply expose its own appropriate methods.<p>This has the added benefit of making the sum function reusable.<p>Personally I prefer this approach to introducing environmental concerns into your code.
评论 #8105551 未加载
kevin1024将近 11 年前
Very cool solution! I&#x27;ve also seen claims that the private methods of modules should not be tested, since they don&#x27;t represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it&#x27;s something to think about!
评论 #8105570 未加载
评论 #8105561 未加载
评论 #8105569 未加载
mthenw将近 11 年前
Don&#x27;t test methods. Test behaviour that stands behind them. Unit in &quot;unit testing&quot; stands for behaviour not method&#x2F;function. Private methods are private because they should not be exposed outside, never. Changing internal implementation of module should not crash test suite.
backspaces将近 11 年前
Why aren&#x27;t you discussing the es6 loader which is available now?<p><a href="https://github.com/ModuleLoader/es6-module-loader" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ModuleLoader&#x2F;es6-module-loader</a><p>It can deal with both AMD and CommonJS modules, as well as es6 import&#x2F;export. It does not need traceur and will work with today&#x27;s JS. And is built upon the standards based System.js which basically provide loader hooks for node, JS, and even Web Components if they so desire.<p>It is sure nice to get rid of the forrest of &lt;script&gt; tags and not be concerned about order of dependencies.
qubyte将近 11 年前
I gave a lightning presentation on this subject last month. A better solution is to put the private methods into (sub)modules. This makes them public to the file system and gives you the ability to tune what you make public via your module API. Ideal for testing purposes and good for module structure in my opinion. The slides can be found here: <a href="https://speakerdeck.com/qubyte/writing-testable-private-methods-with-node-dot-js-modules" rel="nofollow">https:&#x2F;&#x2F;speakerdeck.com&#x2F;qubyte&#x2F;writing-testable-private-meth...</a>
评论 #8105600 未加载
derickbailey将近 11 年前
exposing methods for the purpose of testing is bad design, whether or not you are only doing it in a test environment. if you have a method that is sufficiently complex and warrants its own testing, put it in it&#x27;s own module file and test that module file on it&#x27;s own - no need to break your design and modify your runtime module exports based on runtime environment checks<p><a href="http://lostechies.com/derickbailey/2014/01/03/semantics-modules-and-testing-why-and-how-i-test-internal-components-not-private-methods/" rel="nofollow">http:&#x2F;&#x2F;lostechies.com&#x2F;derickbailey&#x2F;2014&#x2F;01&#x2F;03&#x2F;semantics-modu...</a>