我看到許多問題詢問“如何”以特定語言進(jìn)行單元測試，但沒有問題詢問“什么”，“為什么”和“何時(shí)”。它是什么？它對我有什么作用？我為什么要使用它？我什么時(shí)候應(yīng)該使用它？有哪些常見的陷阱和誤解
2 回答
江戶川亂折騰
TA貢獻(xiàn)1851條經(jīng)驗(yàn) 獲得超5個(gè)贊
粗略地說，單元測試是與測試代碼隔離地測試代碼的各個(gè)部分。我想到的直接好處是：
運(yùn)行測試變得自動(dòng)化且可重復(fù)
與通過GUI進(jìn)行點(diǎn)擊測試相比，您可以進(jìn)行更精細(xì)的測試
請注意，如果您的測試代碼寫入文件，打開數(shù)據(jù)庫連接或通過網(wǎng)絡(luò)執(zhí)行某些操作，則將其更恰當(dāng)?shù)貧w類為集成測試。集成測試是一件好事，但不要與單元測試相混淆。單元測試代碼應(yīng)該簡短，優(yōu)美且易于執(zhí)行。
查看單元測試的另一種方法是先編寫測試。這就是所謂的測試驅(qū)動(dòng)開發(fā)（TDD）。TDD具有其他優(yōu)勢：
您無需編寫推測性的“將來可能會(huì)需要”代碼，僅足以使測試通過
您編寫的代碼始終包含在測試中
通過首先編寫測試，您不得不考慮如何調(diào)用代碼，從長遠(yuǎn)來看，這通常可以改善代碼的設(shè)計(jì)。
如果您現(xiàn)在不進(jìn)行單元測試，建議您開始使用它。獲得一本好書，幾乎任何xUnit-book都可以做，因?yàn)檫@些概念之間可以很容易地轉(zhuǎn)移。
有時(shí)編寫單元測試會(huì)很痛苦。當(dāng)這種方式得到解決時(shí)，請嘗試尋找可以幫助您的人，并抵制“只寫該死的代碼”的誘惑。單元測試很像洗碗。它并不總是那么令人愉快，但是可以使您的隱喻廚房保持清潔，并且您真的希望它保持清潔。:)
編輯：盡管我不確定這是否如此普遍，但我想到了一個(gè)誤解。我聽說一個(gè)項(xiàng)目經(jīng)理說，單元測試使團(tuán)隊(duì)將所有代碼編寫兩次。如果看起來和感覺是那樣，那么，您做錯(cuò)了。編寫測試不僅通常可以加快開發(fā)速度，而且還為您提供了一個(gè)方便的“現(xiàn)在我已經(jīng)完成”的指示符，而您本來可以沒有這些。
ITMISS
TA貢獻(xiàn)1871條經(jīng)驗(yàn) 獲得超8個(gè)贊
我不同意Dan（盡管更好的選擇可能只是不回答）...但是...
單元測試是編寫代碼以測試系統(tǒng)行為和功能的過程。
顯然，測試可以提高代碼的質(zhì)量，但這只是單元測試的膚淺優(yōu)勢。真正的好處是：
在確保不更改行為（重構(gòu)）的同時(shí)，更輕松地更改技術(shù)實(shí)現(xiàn)。可以對經(jīng)過正確單元測試的代碼進(jìn)行積極的重構(gòu)/清理，而幾乎不會(huì)在不注意的情況下破壞任何內(nèi)容。
在添加行為或進(jìn)行修復(fù)時(shí)使開發(fā)人員充滿信心。
記錄您的代碼
指示代碼中緊密耦合的區(qū)域。很難對緊密耦合的代碼進(jìn)行單元測試
提供一種使用您的API并盡早發(fā)現(xiàn)困難的方法
指示不太緊密的方法和類
您應(yīng)該進(jìn)行單元測試，因?yàn)檫@樣做符合您的利益，可以為客戶提供可維護(hù)的優(yōu)質(zhì)產(chǎn)品。
我建議您將其用于對現(xiàn)實(shí)行為進(jìn)行建模的任何系統(tǒng)或系統(tǒng)的一部分。換句話說，它特別適合于企業(yè)發(fā)展。我不會(huì)將其用于一次性/實(shí)用程序。我不會(huì)將其用于測試有問題的系統(tǒng)部分（UI是一個(gè)常見示例，但并非總是如此）
最大的陷阱是開發(fā)人員測試的單元太大，或者他們將方法視為單元。如果您不了解控制反轉(zhuǎn)，則尤其如此-在這種情況下，單元測試將始終轉(zhuǎn)變?yōu)槎说蕉思蓽y試。單元測試應(yīng)該測試個(gè)體行為-大多數(shù)方法都有許多行為。
最大的誤解是程序員不應(yīng)進(jìn)行測試。只有糟糕或懶惰的程序員才會(huì)相信這一點(diǎn)。蓋屋頂?shù)募一锊粦?yīng)該測試嗎？更換心臟瓣膜的醫(yī)生是否應(yīng)該不測試新瓣膜？只有程序員才能測試他的代碼是否達(dá)到了他的預(yù)期目標(biāo)（QA可以測試極端情況-告訴人們要做程序員不希望的事情時(shí)代碼的行為，客戶可以進(jìn)行驗(yàn)收測試-代碼可以做到嗎客戶為此支付了什么費(fèi)用）
蠱毒傳說
TA貢獻(xiàn)1895條經(jīng)驗(yàn) 獲得超3個(gè)贊
與“只是打開一個(gè)新項(xiàng)目并測試此特定代碼”相反，單元測試的主要區(qū)別在于它是自動(dòng)化的，因此可重復(fù)。
如果您手動(dòng)測試代碼，則可能會(huì)說服您代碼在當(dāng)前狀態(tài)下運(yùn)行良好。但是大約一周后，如果您對其進(jìn)行了一些修改，該怎么辦？您是否愿意在代碼中有任何更改時(shí)手動(dòng)重新進(jìn)行測試？可能不是:-(
但是，如果您可以在幾秒鐘之內(nèi)隨時(shí)以完全相同的方式單擊一次測試，則只要出現(xiàn)問題，它們就會(huì)立即向您顯示。而且，如果您還將單元測試集成到自動(dòng)化的構(gòu)建過程中，即使在看似完全不相關(guān)的更改在代碼庫的遙遠(yuǎn)部分中破壞了某些內(nèi)容的情況下，它們也將提醒您注意錯(cuò)誤-當(dāng)您什至不會(huì)想到需要重新測試該特定功能。
這是單元測試相對于手工測試的主要優(yōu)勢。但是，等等，還有更多：
單元測試極大地縮短了開發(fā)反饋循環(huán)：如果使用單獨(dú)的測試部門，您可能要花幾周的時(shí)間才能知道代碼中存在錯(cuò)誤，而此時(shí)您已經(jīng)忘記了大部分上下文，因此可能要花幾個(gè)小時(shí)才能完成查找并修復(fù)錯(cuò)誤；OTOH帶有單元測試，反饋周期以秒為單位，并且錯(cuò)誤修復(fù)過程通常遵循“哦，我* t，我忘了在這里檢查這種情況”的意思：-)
單元測試有效地記錄（對您的理解）代碼的行為
單元測試迫使您重新評估設(shè)計(jì)選擇，從而使設(shè)計(jì)更簡單，更簡潔
反過來，單元測試框架使您可以輕松編寫和運(yùn)行測試。
- 2 回答
- 0 關(guān)注
- 692 瀏覽
添加回答
舉報(bào)
0/150
提交
取消