這可能是一個廣泛且有爭議的問題......但我們現在就去。Javascript單元測試最佳實踐
我從來沒有做過JavaScript的單元測試前，我想知道最好的做法是關於其部署的。
單元測試本身非常簡單。 （其簡單的創建自己的單元測試或使用現有的框架如QUnit。）
我的問題是各地部署的最佳實踐;單元測試代碼應該部署到生產環境中嗎？
例如：我有一個對象'人'的功能'getname（）';那麼我有相應的單元測試這個資產，這個名字是我所期望的。
很簡單吧？......但我從來沒有見過「在野外」一個JavaScript單元測試的一個例子。所以當人們將他們的工作部署到生產環境中時：
我從來沒有單位測試JS之前，所以即時通訊不知道我問正確的問題。
應單元測試代碼部署到生產環境？
號
他們是否剝離單元測試，以節省帶寬？
是。將測試部署到生產也沒有任何好處。
是否有一種特殊的方式來處理單元測試，使他們不進入生產？
把它們寫在不同的文件。不要部署這些文件。明確的命名約定有助於e。 G。所有的測試文件都以.spec.js結束。
有沒有一種工具可以讓我在本地進行單元測試，但將它剝離生產？
是。準備分發包時，您可以使用Grunt，Gulp，Make等跳過測試文件。
你永遠不會有生產附近的單元測試。代碼單位不應該依賴於環境。如果一個代碼單元在本地開發環境中以單向方式工作，它應該在測試或生產環境中以相同的方式工作。
測試應始終以刺激本地部署之前運行。
測試代碼不應在生產過程中運行部署 - 相反，它應該被用來通過構建中，如Cl或QA測試部署環境（看看jenkins持續集成服務器和karma跑步測試，完美適用於這些場景）。擁有獨立的qa環境將允許您私下鏡像生產並檢查發佈後遇到的錯誤。
這很明顯，但測試也應該在本地運行。
使用持續集成服務器來管理您的部署。通常的做法是如果遇到測試失敗，則表示應用程序尚未準備好進行產品發佈，從而使構建失敗。
然後，您應該使用與CI或QA環境匹配的標記應用程序（假設您使用git標記對版本進行版本控制的快照）（假設所有測試都通過），並將其用作簽出生產應用程序的指標，表明它已準備好進行產品發佈和部署。
您不應在生產部署期間運行測試，而應在生產前的環境中運行測試。
這當然是過於簡化，您的情況可能會根據您的應用程序需求而有所不同。
快樂！
不要測試getter和setter ... –
好點。 getters/setter粒度太細。我只是用它作爲例子。假設這是一個複雜得多的函數，通過第三方api獲取數據，一旦我編寫了相應的單元測試，它是否應該「按原樣」直接部署到生產環境中？ – X0r0N
_這可能是一個廣泛的，的確。策略因框架/可用工具而異。你是在談論一個node.js項目，一些像Angular，Ember這樣的客戶端，或者是由你的ASP頁面提供的一些JavaScript。你可能想要更具體一點，以便我們能夠知道要關注什麼上。 – Lars