2013-03-10 13 views
17

現在、nodejsアプリケーションのテストを書いています。 は、私はこのようなモジュールを持っていることを前提としていますnodejsでユニットテストの 'private'ユーティリティ関数を使う方法

module.exports = function myModule(moduleParam) { 
    var someVar; 
    .... 
    .... 
    function helper(param) { 
     return param + someVar; 
    } 
    return { 
     doSomething: function (bar) { 
      .... 
      .... 
      var foo = helper(bar); 
      .... 
      .... 
     } 
    }; 
}; 

「ヘルパー」関数のみをモジュール内で有用であると外部に露出されるべきではないと仮定します。

テストするための「ベストプラクティス」とは何ですか? (もちろん、私はdoSomething関数を全体としてテストすることができますが、このように 'ヘルパー'関数は特定の状況で 'ブラックボックス'形式でテストされます)。

私はnodeunitをテストフレームワークとして使用していますが、必要に応じて変更できます。

+0

Iドンそれはあなたがローカルスコープの変数にアクセスする必要があるからです。 – Bergi

+0

あなたが書くことができるからですあなたが実際にテストを実行している場合は、輸出に別の機能を追加するだけの機能ですか? – phenomnomnominal

+0

@phenomnomnominal、いくつかの 'test'グローバル変数が定義されているか、このようなsometingがある場合にのみエクスポートされる関数のようなものですか? – ArtoAle

答えて

22

あなたはテストしません。ユニットテストはブラックボックステストです。これは、あなたがテストする唯一のことは、パブリックインターフェイスとも呼ばれる契約だということです。

これらのようなプライベート関数は、パブリックなもののリファクタリングでのみ発生する可能性があります。

したがって、TDDを使用すると、プライベート関数が暗黙的にテストされます。

これは間違っていると感じる場合は、あなたの構造が間違っているためです。次に、私的なものを余分なモジュールに移動することについて考えるべきです。

+1

それは私が考えていたものでした(他の再利用可能な機能のために)。私はそれらがリファクタリングから来るだけかもしれないことに同意しません... Javaプライベートメソッドは、公開されたもののリファクタリングから出てくるのですか?私はそうとは思わない...とにかく、私は 'モジュールへの移行'戦略は受け入れられるかもしれないと思うが、私は、依存関係が成立することに賛成して失われたクロージャスコープについて疑問を呈している。良いこと – ArtoAle

+0

TDDに厳密に従えば、Javaでもすべてのプライベートメソッドは1つ(またはそれ以上)のパブリックメソッドのリファクタリングの結果のみになります。しかし、とにかく、私はそれが行く方法だと思う:-) –

+0

私はこの厳密な定義を認識していませんでした:)この言葉では、私はあなたが答えは正しいと考えられると思います。 TDDについてのこのような「声明」を見つけるためのリンクを教えてください。 ありがとう – ArtoAle

8

私はテストはユニットテストとTDD(this SO answerが良いの引数になります)を超えた便利なツールであることがわかりましたので、私はあなたのような場合に支援するためのNPMパッケージ作られた:require-fromを。あなたの例では

これは、あなたがそれを使用する方法である:

モジュール-file.js:-file.jsをインポート

function helper(param) { 
    return param + someVar; 
} 

module.exports = function myModule(moduleParam) { 
    var someVar; 
    .... 
    .... 
    return { 
     doSomething: function (bar) { 
      .... 
      .... 
      var foo = helper(bar); 
      .... 
      .... 
     } 
    }; 
}; 
module.helperExports = helper; 

var requireFrom = require('require-from'); 
var helper = requireFrom('helperExports', './module-file')); 
var public = requireFrom('exports', './module-file')); // same as require('./module-file') 
+0

Mmm ...私の質問ではありません:私はあなたのツールは "公共"と "個人"の輸出を分けているので便利だと私は同意しますが、私の質問はTDDでこのような状況に近づく方法に関するものでした。コードを書く方法と正直なところ、テストの唯一の目的のために何かを明示的にエクスポートすることが良い練習があるかどうかを知りたかったのですが、TDDでは、より良い、再利用可能なコードを書く:) – ArtoAle

+0

パターンのようなベストプラクティスは状況によって異なります。開発者はトレードオフと判断力を考慮する必要があります。機能単位を独立してテストし、安定したパブリックAPIを維持し、公開されるものを最小限に抑えることが重要であることを考えると、ライブラリは別のモジュールにコードを抽出する代わりの方法を提供します。たとえば、関連するコードをまとめたり、他のモジュールが抽出したコードに依存し始めるリスクを避けたい(大規模なチームで発生する)だから答えがあなたにとって今は役に立っていなくても、それは将来、あるいは他の人たちのものかもしれません。 – DEADB17

+0

ところで、サルパッチはありません。このメカニズムは、通常のノードのエクスポートと同じです。 – DEADB17

関連する問題