聊聊前端單元測試

講講前端的單元測試

前言

我希望你看完這篇文章後，能夠對你的開發流程有所啟發，那就是我寫這篇文章的初衷了。

什麼是單元測試

顧名思義單元測試就是測試最小單元，我們的單元可能是一個函式，一個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）

1. Add a test

在測試驅動開發中，每個新特性都以編寫測試開始。編寫一個測試，它定義了一個函式或一個函式的改進，這應該是非常簡潔的。要編寫測試，開發人員必須清楚地瞭解該特性的規範和要求。開發人員可以透過use cases和user  stories來完成這個任務，以覆蓋需求和異常條件，並且可以在任何適合於軟體環境的測試框架中編寫測試。它可以是現有測試的修改版本。這是測試驅動開發與編寫程式碼後編寫單元測試的一個區別特性：它使開發人員在編寫程式碼之前關注需求，這是一個微妙但重要的區別。

2、重構

在我們維護程式碼的過程中，必須定期清理不斷增長的程式碼。新程式碼可以從方便的地方轉移到它更符合邏輯的地方。重複的程式碼必須被刪除。物件、類、模組、變數和方法名應該清楚地表示它們當前的用途，因為新增了額外的功能，會導致很難去分辨命名的意義。等到程式碼不斷的增加會使得規範的命名和刪除重複程式碼越來越收益。

3、開發風格轉換

測試程式碼應該在功能程式碼之前去寫，這是被認為有更多的好處。它能確定這個程式是為可測試而寫的，因為開發者需要從一開始就必須考慮如何編寫測試程式，而不是後面再去考慮。此外，寫測試程式碼能夠更深的理解需求。

作者：Victor細節
連結：