node.js用に作成されたアプリケーションを単体テストするためにモカを使用しています

モジュールにエクスポートされていない関数を単体テストすることは可能ですか？

例：

私はこのように定義された多くの関数を持っています foobar.js

function private_foobar1(){
    ...
}

function private_foobar2(){
    ...
}

パブリックとしてエクスポートされたいくつかの関数：

exports.public_foobar3 = function(){
    ...
}

テストケースは次のように構成されています。

describe("private_foobar1", function() {
    it("should do stuff", function(done) {
        var stuff = foobar.private_foobar1(filter);
        should(stuff).be.ok;
        should(stuff).....

private_foobar1はエクスポートされないため、明らかにこれは機能しません。

プライベートメソッドを単体テストする正しい方法は何ですか？モカにはそれを行うためのいくつかの組み込みメソッドがありますか？

関数がモジュールによってエクスポートされない場合、モジュールの外部のテストコードから呼び出すことはできません。これはJavaScriptの仕組みによるものであり、Mocha自体ではこれを回避することはできません。

プライベート関数のテストが正しいことだと判断したいくつかの例では、モジュールがテスト設定で実行されているかどうかを確認するためにモジュールがチェックするいくつかの環境変数を設定しました。テストセットアップで実行する場合は、テスト中に呼び出すことができる追加の関数をエクスポートします。

ここでは「環境」という言葉を大まかに使用しています。これはprocess.env、「現在テスト中です」というモジュールと通信できるチェックなどを意味する場合があります。私がこれをしなければならなかった例はRequireJS環境であり、私はmodule.configこの目的のために使用しました。

再配線モジュールを確認してください。モジュール内のプライベート変数と関数を取得（および操​​作）できます。

したがって、あなたの場合、使用法は次のようになります：

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).....

GoogleのエンジニアであるPhilip Waltonがブログで説明している、プライベートメソッドをテストするための非常に優れたワークフローを次に示します。

原理

• 通常通りコードを書く
• プライベートメソッドを別のコードブロックでオブジェクトにバインドし、_たとえば、
• 開始コメントと終了コメントでコードブロックを囲む

次に、ビルドタスクまたは独自のビルドシステム（grunt-strip-codeなど）を使用して、本番ビルド用にこのブロックを削除します。

テストビルドはプライベートAPIにアクセスできますが、本番ビルドはアクセスできません。

スニペット

次のようにコードを記述します。

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
}())

そして、そのようなあなたの不快なタスク

grunt.registerTask("test", [
  "concat",
  "jshint",
  "jasmine"
])
grunt.registerTask("deploy", [
  "concat",
  "strip-code",
  "jshint",
  "uglify"
])

より深く

後の記事では、「プライベートメソッドのテスト」の「理由」について説明しています。

シンプルにしたい場合は、プライベートメンバーもエクスポートしますが、パブリックAPIから明確に分離します。たとえば、プレフィックスを付ける_か、単一のプライベートオブジェクトの下にネストします

var privateWorker = function() {
    return 1
}

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

module.exports = {
    doSomething: doSomething,
    _privateWorker: privateWorker
}

：私はあなたが有用見つけるかもしれないことを、この目的のためにNPMパッケージを作っ必要-から

基本的に、非公開メソッドは次の方法で公開します。

module.testExports = {
    private_foobar1: private_foobar1,
    private_foobar2: private_foobar2,
    ...
}

注： もちろんtestExports、任意の有効な名前を使用できますexports。

そして別のモジュールから：

var requireFrom = require('require-from');
var private_foobar1 = requireFrom('testExports', './path-to-module').private_foobar1;

Internal（）という名前の関数を追加し、そこからすべてのプライベート関数を返します。次に、このInternal（）関数がエクスポートされます。例：

function Internal () {
  return { Private_Function1, Private_Function2, Private_Function2}
}

// Exports --------------------------
module.exports = { PublicFunction1, PublicFunction2, Internal }

次のような内部関数を呼び出すことができます。

let test = require('.....')
test.Internal().Private_Function1()

私はこのソリューションが一番好きです：

• 一つだけの関数の内部は、（）は常にエクスポートされます。このInternal（）関数は、プライベート関数をテストするために常に使用されます。
• 実装は簡単です
• 量産コードへの影響が少ない（1つの追加機能のみ）

私は続い@barwin解答とユニットテストがで作ることができるか確認のReWireモジュール。このソリューションが機能することを確認できます。

モジュールは、パブリックとプライベートの2つの部分で必要です。パブリック関数の場合、標準的な方法でそれを行うことができます：

const { public_foobar3 } = require('./foobar');

プライベートスコープの場合：

const privateFoobar = require('rewire')('./foobar');
const private_foobar1 = privateFoobar .__get__('private_foobar1');
const private_foobar2 = privateFoobar .__get__('private_foobar2');

主題について詳しく知るために、モジュール全体のテストを行った実用的な例を作成しました。テストにはプライベートスコープとパブリックスコープが含まれます。

詳細については、主題を完全に説明している記事（https://medium.com/@macsikora/how-to-test-private-functions-of-es6-module-fb8c1345b25f）を確認することをお勧めします。コードサンプルも含まれています。

これが必ずしもあなたが探している答えではないことは知っていますが、私が見つけたのは、ほとんどの場合、プライベート関数がテストする価値がある場合、それ自体のファイルにある価値があるということです。

たとえば、次のように、パブリックメソッドと同じファイルにプライベートメソッドを置くのではなく...

src / thing / PublicInterface.js

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);
}

...次のように分割します。

src / thing / PublicInterface.js

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);
}

src / thing / internal / helper1.js

export function helper1 (x) {
    return 2 * x;
}

src / thing / internal / helper2.js

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

そうすれば、Rewireやその他の「マジック」を使用しなくても、簡単にテストhelper1しhelper2て現状のままでテストできます（これは、デバッグ中、またはTypeScriptに移行しようとするときに問題があることはわかっています）。新しい同僚のための理解可能性）。そして、それらがと呼ばれるサブフォルダinternalまたはそのような場所にあると、意図しない場所での偶発的な使用を回避するのに役立ちます。

PS：「プライベート」メソッドのもう1つの一般的な問題は、ヘルパーをテストpublicMethod1しpublicMethod2てモックしたい場合、通常、Rewireのようなものが必要です。ただし、それらが別々のファイルにある場合は、Proxyquireを使用して実行できます。これは、Rewireとは異なり、ビルドプロセスに変更を加える必要がなく、読み取りやデバッグが簡単で、TypeScriptでもうまく機能します。

プライベートメソッドをテストに使用できるようにするには、次のようにします。

const _myPrivateMethod: () => {};

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

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

module.exports = methods;