講講前端的單元測試
前言
我希望你看完這篇文章后，能夠對你的開發流程有所啟發，那就是我寫這篇文章的初衷了。
什么是單元測試
顧名思義單元測試就是測試最小單元，我們的單元可能是一個函數，一個button的樣式，一個文案等等都可能是一個單元。那么我們在做需求的時候沒有必要將所有的單元都做測試，那可能測試代碼要比需求代碼多得多呢。我們在做需求之前需要提前想好我們的測試用例，并針對測試用例編寫測試代碼，然后寫需求代碼。
為什么做單元測試
做前端的很多人可能不會去寫單元測試，認為這是一個浪費時間的事情，我們有這么多的需求，哪還有時間跟精力去編寫測試代碼？這么想當然沒有錯，但是當一個項目由多人一起維護的時候，假如A寫了一個頁面，B去維護A的頁面加了一些邏輯，C去維護該頁面再添加一些邏輯，當A再去維護這個頁面的時候，可能就會發現已經不是當初他認識的代碼了，函數也不是原來的語義，大部分的變量不知道干什么用的。那么A需要捋清楚B、C的邏輯，在B、C的基礎上小心翼翼的編寫新的需求，生怕哪一步寫錯，導致線上的代碼出錯。長此以往下去代碼越來越難以維護，越來越少的人能看懂頁面內的邏輯，糊墻試代碼將頁面堵得水泄不通！當然這是最壞的想法，我們不防往好的一方面來想，假如我們每個人的編碼水平都很高，都按著規范去寫代碼，A寫完代碼，B去維護的時候將A的代碼全部了解之后健壯了新的代碼，C去維護的時候再把A、B的代碼全部掌握后再去寫代碼，一個月，三個月。。。
所以依賴我們自覺去維護代碼首先對我們個人能力有很大要求，其次對我們精力也是恨到的浪費。我們要時刻注意是否自己的代碼影響到別人的代碼。從長遠考慮，單元測試是一個大型項目的必然選擇。
我們講的單元測試，只是測試代碼的最小單元，一個函數就是一個單元，在這里我要提倡大家去學習一下函數式編程。
單元測試賦予我們的能力
在寫這個答案之前我需要講一下TDD（測試驅動開發）。
你問我什么是TDD？
TDD是一種思維，測試來推動整個開發的進行的思維。你在開發需求的時候或許不必寫單元測試，但是你必須要懂得TDD，才能讓你的代碼看起來得體。
或許你到現在為止并不清楚什么是TDD，接下來我用簡單的語言來闡述一下。
正如上面的例子中A、B、c遇到的問題，我們用TDD的思維來重新寫這個頁面。那么A在拿到需求之后首先應該考慮所需要的測試用例有哪些，然后對這些測試用例編寫測試代碼，接著去編寫業務代碼。
什么是TDD
TDD （test-driven development）
- Add a test
在測試驅動開發中，每個新特性都以編寫測試開始。編寫一個測試，它定義了一個函數或一個函數的改進，這應該是非常簡潔的。要編寫測試，開發人員必須清楚地了解該特性的規范和要求。開發人員可以通過use cases和user stories來完成這個任務，以覆蓋需求和異常條件，并且可以在任何適合于軟件環境的測試框架中編寫測試。它可以是現有測試的修改版本。這是測試驅動開發與編寫代碼后編寫單元測試的一個區別特性：它使開發人員在編寫代碼之前關注需求，這是一個微妙但重要的區別。
2、重構
在我們維護代碼的過程中，必須定期清理不斷增長的代碼。新代碼可以從方便的地方轉移到它更符合邏輯的地方。重復的代碼必須被刪除。對象、類、模塊、變量和方法名應該清楚地表示它們當前的用途，因為添加了額外的功能，會導致很難去分辨命名的意義。等到代碼不斷的增加會使得規范的命名和刪除重復代碼越來越收益。
3、開發風格轉換
測試代碼應該在功能代碼之前去寫，這是被認為有更多的好處。它能確定這個程序是為可測試而寫的，因為開發者需要從一開始就必須考慮如何編寫測試程序，而不是后面再去考慮。此外，寫測試代碼能夠更深的理解需求。
