我對單元測試和測試驅動(dòng)開(kāi)發(fā)的見(jiàn)解

什么是單元測試

（廢話(huà)想說(shuō)一些：如果我們聽(tīng)到一個(gè)陌生的概念，不去追問(wèn)它是什么，它有什么用？直接進(jìn)行任務(wù)去完成這個(gè)概念描述的事，那么，我們可能很難理解我們?yōu)槭裁匆@么做，也可能做不好。）

• 概念解釋
  單元測試是針對一個(gè)工作單元設計的測試。這里的工作單元一般是指對一個(gè)方法的一個(gè)要求。
• 單元測試優(yōu)點(diǎn)
  我們可以集中精力針對于一個(gè)特定的工作單元進(jìn)行測試，排除其它邏輯干擾，使編寫(xiě)測試更加容易。如果測試失敗，也能很快鎖定哪里出現缺陷。
• 單元測試的特征

1. 與其它代碼隔離：?jiǎn)卧獪y試代碼不影響其它代碼，需建立獨立項目文件；
2. 與其他開(kāi)發(fā)人員隔離：每個(gè)開(kāi)發(fā)人員編寫(xiě)的單元測試不互相干擾；
3. 有針對性：?jiǎn)卧獪y試是針對一個(gè)特定的工作單元編寫(xiě)的；
4. 可重復：?jiǎn)卧獪y試可以重復運行，并且保證每次結果都正確；
5. 可預測：能夠確定方法輸入X，將返回Y。

阻礙開(kāi)發(fā)人員編寫(xiě)單元測試可能的原因

大部分公司即使要求編寫(xiě)單元測試也是先寫(xiě)業(yè)務(wù)代碼，再編寫(xiě)測試代碼去測試。由于開(kāi)發(fā)人員水平不齊，業(yè)務(wù)代碼不能保證質(zhì)量，可能導致難以測試。我收集了經(jīng)常遇到一些阻礙測試的問(wèn)題。

• 依賴(lài)其它類(lèi)
• 業(yè)務(wù)邏輯沒(méi)有返回值，直接影響數據庫或者其它
• 業(yè)務(wù)邏輯復雜，需要很多驗證
• 其它外部資源：數據庫、文件、配置、緩存等

當然還有很多情況阻止著(zhù)我們編寫(xiě)單元測試。解決的辦法遵循三個(gè)點(diǎn)：
一是編寫(xiě)業(yè)務(wù)代碼嚴格執行單一職責原則；
二是面向接口編程，使用依賴(lài)注入；
三是利用工具模擬外部資源。

== 另外一點(diǎn) ==
我們總將一些靜態(tài)資源封裝成靜態(tài)類(lèi)，當這些類(lèi)也參與業(yè)務(wù)邏輯，那么就會(huì )影響編寫(xiě)單元測試。比如：架構組將操作Redis的庫編寫(xiě)成靜態(tài)類(lèi)，如果執行測試將會(huì )影響Redis數據。令人頭疼的是，基本上所有的免費框架都不支持Mock靜態(tài)類(lèi)。目前，我采取的方法是使用JustMock的付費功能。經(jīng)驗有限，希望發(fā)到博客有大神指出解決方案。

測試驅動(dòng)開(kāi)發(fā)——TDD

• TDD 的理念
  當我們拿到需求，按照瀑布流開(kāi)發(fā)的模式進(jìn)行的發(fā)，應當是創(chuàng )建業(yè)務(wù)項目，編寫(xiě)業(yè)務(wù)代碼，需要的話(huà)編寫(xiě)測試代碼，測試工程師測試，然后驗收發(fā)布。
  而在TDD中，我們需要面對需求編寫(xiě)測試代碼。先寫(xiě)測試代碼，我相信很多人都會(huì )覺(jué)得很困惑，沒(méi)有邏輯，沒(méi)有方法，測試代碼測試什么？TDD的理念是測試先行。
• TDD 的好處

1. 嚴格根據TDD思維，遵循SOLID原則 開(kāi)發(fā)能保證代碼質(zhì)量
2. TDD 確保了代碼與業(yè)務(wù)需求高度一致性
3. TDD 鼓勵創(chuàng )建更簡(jiǎn)單、針對性更強的庫和API
4. TDD 要落實(shí)測試單元，需要鼓勵與業(yè)務(wù)方持續溝通
5. TDD 有助于清除無(wú)用代碼。無(wú)用代碼實(shí)際上維護成本非常高
6. TDD 提供了內置的回歸測試。再次執行測試代碼可檢查修改一個(gè)方法邏輯會(huì )不會(huì )影響到其它現有功能
7. TDD 阻止遞歸錯誤。每個(gè)測試都針對系統缺陷，那么，同樣的錯誤不會(huì )再次發(fā)生
8. TDD 開(kāi)發(fā)應用程序的系統是開(kāi)放的、可擴展的、靈活的系統。

以上都是廢話(huà)，我還沒(méi)完整體驗過(guò)真正的TDD開(kāi)發(fā)線(xiàn)上系統。理解測試驅動(dòng)開(kāi)發(fā)的理念，能讓我們編寫(xiě)更漂亮的代碼倒是真的。

• TDD 如何完成軟件開(kāi)發(fā)

TDD 的三個(gè)階段：

1. 紅燈階段
   編寫(xiě)貼合需求的測試代碼，盡量保證覆蓋需求每個(gè)點(diǎn)。
2. 綠燈階段
   編寫(xiě)適當代碼，使測試通過(guò)。合理命名一個(gè)方法名，然后簡(jiǎn)短完成方法?？赡芤粋€(gè)范湖bool型的方法只寫(xiě)一個(gè)返回代碼。
3. 重構階段
   這個(gè)階段是真正完成業(yè)務(wù)邏輯的階段。因為我們編寫(xiě)的測試代碼已經(jīng)完整滿(mǎn)足業(yè)務(wù)需要，所以，我們只需要根據測試代碼，編寫(xiě)完業(yè)務(wù)代碼，再通過(guò)測試即可。

完成一項工程，不要期待只走一遍流程就完成了，寫(xiě)代碼從來(lái)沒(méi)有容易的事，很多時(shí)候，我們都需要反反復復修改，不僅僅是需求更改，也為了讓我們“以前”寫(xiě)過(guò)的代碼更整潔。

我目前還是覺(jué)得，很艱難能堅持TDD模式開(kāi)發(fā)，很難讓你的團隊的伙伴都轉變思維，從測試代碼開(kāi)始。但不妨礙我們去體會(huì )TDD，我們帶著(zhù)測試的思維去寫(xiě)業(yè)務(wù)代碼，時(shí)刻都想著(zhù)，我這樣設計會(huì )不會(huì )很難測試。如果我們的代碼讓我們很難測試，我相信他大概率也不是好的代碼。

原文轉自：https://www.cnblogs.com/jimizhou/p/11435807.html