在你開始學(xué)習(xí)任何新的技能或概念之前，我建議你先看看我的課程“快速學(xué)習(xí)任何東西的10個步驟”。

昨天有人提醒我，仍然有很多人還沒有真正理解單元測試的目的。

最近5年左右發(fā)生了一個有趣的轉(zhuǎn)變。

大約5年前，當(dāng)我建議在創(chuàng)建代碼時使用TDD或者只是做一些單元測試時，我會得到可怕的回應(yīng)，許多開發(fā)人員和管理人員不明白為什么單元測試很重要，認(rèn)為這只是額外的工作。

最近，當(dāng)我聽到人們談?wù)搯卧獪y試時，幾乎每個人都同意單元測試是一個好主意，但不是因為他們理解為什么，而是因為現(xiàn)在編程界期待著單元測試。

沒有理解的進步只是在一個隨機的方向上前進。

回到基本點

單元測試根本不是測試。

單元測試，尤其是測試驅(qū)動開發(fā)，是一種設(shè)計或?qū)崿F(xiàn)活動，而不是一種測試活動。

單元測試有兩個主要好處，其中大部分價值都歸第一個：

1. 引導(dǎo)您的設(shè)計實現(xiàn)松散耦合和良好充實。如果進行測試驅(qū)動開發(fā)，它會將您編寫的代碼限制為只需要的代碼，并幫助您以小步的方式改進代碼。

2. 為重構(gòu)和代碼的小改動提供快速自動回歸。

我不是說這就是全部的價值，但這是最重要的兩個。

單元測試強制您實際使用正在創(chuàng)建的類，如果類太大并且包含多個責(zé)任，則會對您進行懲罰。

通過這種痛苦，您可以將設(shè)計更改為更具內(nèi)聚性和松散耦合性。

您可以考慮您的類可能面臨的更多場景，并確定這些場景的行為，從而驅(qū)動類的設(shè)計和完整性。

完成后，您將得到一些自動化測試，這些測試不能確保系統(tǒng)正常工作，但可以確保功能不會更改。

實際上，在創(chuàng)建代碼時，大部分的價值都是在創(chuàng)建單元測試的過程中產(chǎn)生的，這就是為什么在編寫代碼之后再回去編寫單元測試是沒有意義的主要原因之一。

有缺陷的思維

下面是一些不好的no no，它們表明您不了解單元測試：

• 您在編寫代碼之后編寫單元測試，而不是在編寫代碼期間或之前。

• 您讓其他人為您的代碼編寫單元測試。

• 您編寫集成測試或系統(tǒng)測試并調(diào)用它們，僅僅因為它們直接調(diào)用代碼中的方法。

• 您讓QA編寫單元測試，因為它們畢竟是測試。

單元測試有很多工作要寫，如果你想用單元測試來覆蓋整個系統(tǒng)，并有相當(dāng)多的代碼覆蓋率，你所說的是大量的工作。

如果您沒有獲得單元測試的第一個主要價值，改進您的設(shè)計，那么編寫單元測試就是在浪費大量的時間和金錢。

老實說，你認(rèn)為把一堆你已經(jīng)寫過的代碼或者其他人已經(jīng)寫過的代碼交給每個人來編寫單元測試會怎么樣？

你認(rèn)為僅僅通過添加單元測試而不改變代碼就能神奇地改進代碼嗎？

也許你認(rèn)為回歸的價值如此之高，以至于可以證明這種成本是合理的？

我并不是說不要在遺留代碼中添加單元測試，我是說當(dāng)你在遺留代碼中添加單元測試時，你最好從中獲得你的價值，因為這是一項艱苦的工作，需要花費很多時間。

當(dāng)您觸及遺留代碼時，重構(gòu)該代碼并使用單元測試來指導(dǎo)重構(gòu)后的設(shè)計。

不要認(rèn)為單元測試是神奇的。

單元測試就像一個指導(dǎo)方針，它可以幫助你把問題解決得更清楚。在你已經(jīng)解決了問題之后，再給一個word-working項目添加指導(dǎo)方針是很可笑的。