我剛剛閱讀了關於Javascript的測試驅動開發的這本精彩的書，並且在那裏他提到了創建具有私有成員的對象的一種驚人方式，最初由Douglas Crockford創建，稱爲「功能性遺產」。它是這樣的：功能繼承中的單元測試私有方法

this.funcInh = function() { 
     var privateString = "functional inheritance"; 

     function setPrivateString(string) { 
      privateString = string; 
     } 

     function getPrivateString() { 
      return privateString; 
     } 

     return { 
      setPrivateString: setPrivateString, 
      getPrivateString: getPrivateString 
     }; 
    };

雖然我真的很喜歡創建對象的這種方式，我想知道如何在地球上我可以測試它，不是測試特權功能「setPrivateString」的返回值，其他和「getPrivateString 」。這只是一個例子，但我真的不明白任何方式來測試「私人」功能或特權函數調用他們應該的功能...任何想法？

2011-07-06 Robin Heggelund Hansen

你真的想測試私人嗎？

我認爲就您的公共方法如預期的那樣工作並向「外部世界」提供正確的結果，您不應該關心「盒子內」的工作原理和工作方式。

查看更多關於這一點：Should I test private methods or only public ones?

來源

2011-07-06 09:43:56 Laimoncijus

我部分同意你的看法。在某些情況下，函數可以給出看起來是正確的回報，而唯一可以確定的方法就是測試一個私有函數......然而，我認爲這對功能繼承是非常困難的... –

從我自己的經驗來看：沒有測試私有者就容易多了 - 如果你的公共方法調用某些私有（它做了別的 - 例如創建文件/在DB/orr上執行任何操作） - 只是測試公共方法的結果並且像預期的那樣，另外測試諸如文件，DB上的數據等外部事物的創建/修改/刪除/沒有「知道」私有和他們的實現 - 以這種方式，你總是可以完全改變內部事物，並且測試將在公共結果和所有「外部」資源/數據在結束時一直運行良好 – Laimoncijus

組織的私有成員和職能到另一個類，可你測試。或創建一個公共測試功能，即工作只是在測試環境中，否則拋出由菲利普·沃爾頓，在其博客上谷歌的工程師解釋例外

來源

2013-06-05 14:01:54 Aaaaaaaa

Here is a really good workflow to test your private methods。

原理

編寫代碼通常
綁定您的私有方法的對象在一個單獨的代碼陣營，由開始由_例如紀念其
環繞代碼陣營，並最終意見

然後使用一個構建任務或您自己的構建系統（例如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" 
])

功能繼承中的單元測試私有方法

回答

原理

片段

更多更深

功能繼承中的單元測試私有方法

回答

原理

片段

更多更深

相關問題