Jani Hartikainen講述了如何利用Mocha來進行單元測試 Unit Test Your JavaScript Using Mocha and Chai 。在使用Jsmine，Travis，Karma測試JavaScript (Testing JavaScript with Jasmine, Travis, and Karma) 這篇文章中，Tim Evko展示了怎么通過另一個叫做Jasmine的框架來設置良好的測試流程。這兩個測試框架都是非常流行的，但還有適應別的需求的其他框架。
我在這篇文章前面撰寫的大綱，已經(jīng)講述了它期待怎樣的輸出。這是一切測試的開始：從期望出發(fā)。關于我的代碼庫的一個Jasmine測試像是這樣：
describe('Basic usage', function () {
it('should generate a single product', function () {
// Create a single product
var product = new UserAgent.Product('EvilCorpBrowser', '1.2');
product.setComment('X11', 'Linux', 'en-us');
expect(product.toString())
.toBe('EvilCorpBrowser/1.2 (X11; Linux; en-us)');
});
it('should combine several products', function () {
var userAgent = new UserAgent;
// Create and add first product
var application = new UserAgent.Product('EvilCorpBrowser', '1.2');
application.setComment('X11', 'Linux', 'en-us');
userAgent.addProduct(application);
// Create and add second product
var engine = new UserAgent.Product('Blink', '20420101');
userAgent.addProduct(engine);
expect(userAgent.toString())
.toBe('EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101');
});
it('should update products correctly', function () {
var userAgent = new UserAgent;
// Create and add first product
var application = new UserAgent.Product('EvilCorpBrowser', '1.2');
application.setComment('X11', 'Linux', 'en-us');
userAgent.addProduct(application);
// Update first product
application.setComment('X11', 'Linux', 'nl-nl');
expect(userAgent.toString())
.toBe('EvilCorpBrowser/1.2 (X11; Linux; nl-nl)');
});
});
一旦你對你的API設計的第一個版本完全滿意，是時候開始思考結構和你的代碼庫應該如何被使用。
##模塊加載器兼容性
你或許使用過模塊加載器。使用你的代碼庫的開發(fā)者有可能使用加載器，所以你會希望自己的代碼庫與模塊加載器是兼容的。但兼容哪一個呢?應該怎么從CommonJS，RequireJS，AMD和其他加載器中挑選呢?
實際上，你不需要挑選!通用模塊定義(UMD)是一個目標就是支持多種加載器的規(guī)則。你可以在網(wǎng)上找到不同風格的代碼段，或者從這里 UMD GitHub repository 學習并讓它與你的代碼庫兼容。從其中的某個模板開始，或者使用你喜歡的構建工具 add UMD with your favorite build tool ,你就不必再擔心模塊加載器的問題了。
如果你希望用上ES2015的 import / export 語法，我建議使用Babel和 Babel’s UMD plugin 來將代碼轉換成ES5。通過這個方法你可以在你的項目中使用ES2015,同時生成兼容性良好的代碼庫。
##文檔
我完全贊成在每一個項目中使用文檔。但這通常牽涉到大量的工作，導致編寫文檔被推遲和在最后被遺忘。
###基本信息
文檔的編寫應當從項目的名字和描述之類基本的信息開始。這會對別人明白你的代碼庫做了什么和是否對他們有用有所幫助。
你可以提供像是適用范圍和目標之類的信息來更好的給用戶提供信息，而提供路線圖可以讓他們明白在未來可能會有什么新變化以及他們可以提供怎樣的幫助。
###API，教程和例子
當然，你需要確保用戶知道如何去使用你的代碼庫。這從API文檔開始。教程和例子是很好的補充，但編寫他們會是一個龐大的工作。然而，內(nèi)聯(lián)文檔 Inline documentation 不會這樣。下面是一些利用 JSDoc 的，可以被解析和轉換成文檔頁的注釋
###元任務
一些用戶想對你的代碼庫作出改進。在大多數(shù)情況中，會是貢獻代碼，但有一些會創(chuàng)建一個私人使用的定制版本。對于這些用戶，為類似構建代碼庫，運行測試，生成，轉換和下載數(shù)據(jù)之類的元任務提供文檔很有幫助的。
###貢獻
當你對你的代碼庫進行開源，得到代碼貢獻是很有幫助的。為了引導貢獻者，你可以增加一些關于貢獻代碼的步驟和需要滿足的標準的文檔。這會對你審閱和接納貢獻的代碼和他們正確的貢獻代碼有所幫助。