來源:51Testing軟件測試網(wǎng)
我曾經(jīng)是一個不測試主義者,因為我看不到測試的價值。然后,我試了一段時間,變得對它深信不疑。我收集了一些經(jīng)驗,當然還遠遠不夠。這篇文章總結(jié)了一些我知道的以及我認為我知道的內(nèi)容。
“我不總測試我的代碼,但是當我測試的時候,感覺更好。”—— 我
這是怎么一回事呢?
這,全是因為代碼:
本文主要關(guān)于單元測試,而不是集成測試或端至端的測試,但在某些方面也可用于其他測試。在實踐中,測試很少是單一的或非此即彼的,并且這也不是目的。
單元測試成本低廉,因此應(yīng)該成為測試工作中極大的組成部分。編寫和運行單元測試都很便宜。因為它只查看代碼的特定部分。集成測試則相反,它們包含的代碼更大。
為什么這很重要?
測試可幫助你對你的代碼放心。對一個稍復(fù)雜的問題寫一個解決方案,然后手動測試,你只需要這么做就可以了。有著一定經(jīng)驗的你當然可以自信地發(fā)布代碼,但是結(jié)果卻往往是拋棄了發(fā)現(xiàn)錯誤的首次機會。
測試能讓你體驗?zāi)愕拇a中在極端的條件下是什么樣的。要是傳遞的數(shù)字是負數(shù),會怎么樣,在我們總是假定數(shù)值為正的情況下?要是傳遞的根本就不是數(shù)字,會怎么樣?
“每個人都會寫出 bug,我們都寫過 bug。因此,這不是“你能正確地編寫代碼或一次性寫出正確代碼?”的問題,我們都寫過不正確的代碼。這就是我們所做的一切,我們寫的都是不正確的代碼?!?/span>——Joe Eames《JavaScript. Air 004》
編碼是辛苦,我們都應(yīng)該承認這一點。其中的主要原因之一就是,你需要測試代碼,以獲得它能如期表現(xiàn)的信心,不管是什么代碼。
不相信?這里給出了一些附加參數(shù):
測試過的代碼更好
許多人會告訴你,代碼測試會導(dǎo)致更好的代碼質(zhì)量。這在使用單元測試,并且至少在測試驅(qū)動開發(fā)上有所行動,即使這些行動甚為草率時,尤其如此。原因如下:
如果你的代碼難以測試,那么可能是你代碼沒有寫好。好代碼的定義是什么,這是一個大問題,但這里要強調(diào)的一句話是一個很好的經(jīng)驗法則,也是大多數(shù)人所贊同的,那就是,好的代碼會分離關(guān)注點。有經(jīng)驗的程序員限制功能體以便于只做一件邏輯上的事情就是這個原因。
目標對齊
代碼很難測試可能要么是因為有太多的事情要繼續(xù),要么是因為有太多的依賴(或兩者皆有)??紤]將此視為協(xié)調(diào)利益的一個問題:在編寫未經(jīng)測試的代碼時,在速度(或懶惰)和關(guān)注點分離之間存在著利益沖突,并且短期內(nèi)你的代碼是如何被組織的并沒有那么重要。當代碼必須測試時,你的目標更一致,因為對于寫得好的代碼,更易于寫測試!
像消費者一樣思考
當你首次編寫測試時,你首先要設(shè)計代碼的 API。測試讓你進入代碼消費模式,在這種模式下,你的代碼需要面對其他東西的接口。設(shè)計 API,而不那么關(guān)注內(nèi)部運作將導(dǎo)致一個更佳的 API 設(shè)計,這會導(dǎo)致模塊的更易消耗,從而促進項目代碼的更干凈。
靈感突現(xiàn)
測試會讓你靈機一現(xiàn)。通常情況下,因為它迫使你去思考邊緣情況——零值,10 ^ 12,null 或 undefined。這使得你有機會來思考。去反省,以及了解在陌生的環(huán)境下會發(fā)生什么。僅僅是思考這些的過程,或代碼將面對的其他情況,都經(jīng)常會讓你意識到代碼可以簡化(以及代碼需要如何保護自我)。
這些靈感突現(xiàn)的時刻也可能來自特別令人沮喪的情況之一:當你的代碼和測試不一致的時候。你正處于不知道哪個才正確的兩難境地。如果你碰到這種情況,那么設(shè)計可能有問題,或者你的前提假設(shè)發(fā)生了變化。把它看成是一個好兆頭!你的代碼將會更滿意。
測試可以說明代碼做了什么
沒有人喜歡寫文檔,但當你繼承(從一年前的自己,或其他人)或接口的模塊文檔齊全的時候,絕對是好的。測試可以成為這樣一種途徑,并且還有一個額外的好處是:測試用實際行動證實代碼。就如同極佳的科學(xué)教師,他們不只是用嘴巴告訴你,氫氣易燃,而是充了一個氫氣球,讓它升到天花板上,然后在棍子上放一根點燃的火柴靠近氣球(這是我五年級時特別難忘的時刻之一)。
你知道所有 bug 的共同點嗎?那就是它們經(jīng)過了所有的測試。所以,當你找到一個 bug 的時候,就等于知道測試哪里還需要改進。
測試可以使得更容易地加入項目,因為它們揭示了代碼實際上應(yīng)該做什么。它們告訴你設(shè)計決策,以及初始的開發(fā)人員心里在想什么。
不要擔(dān)心,去重構(gòu)吧
也曾看到過烏七八糟的代碼,但不敢去清理干凈?我在這種情況下要做的首件事是創(chuàng)建測試來找出代碼要做什么。測試可以鎖定功能,用一種很好的方式,使得我們能夠?qū)W⒂凇按髵叱保皇菗?dān)心破壞什么東西。
我見過一些糟糕到讓人不知道它們是做什么的代碼片段。同樣的,人人避之唯恐不及,不但要擔(dān)心會破壞預(yù)期的功能,而且還要擔(dān)心破壞 bug。我認為基于過去的I/ O 的大型測試集是非常值得的投資。
有趣的是,擔(dān)心和快樂的心情是成反比的。總之是一種此消彼長的狀態(tài)。
自信地創(chuàng)造價值和正確的產(chǎn)品
正確的代碼比不正確的代碼更有價值。一切幫助你的代碼比以前更正確的東西都值得看一看,就這么簡單。發(fā)布正確的代碼隨著時間的推移會構(gòu)建起信任,而信任是一筆寶貴的財富。
魚與熊掌不可得兼
這里有一個技巧:不要在試圖解決問題的同時,設(shè)計一個很好的解決方案。來自于 Ian Cooper 關(guān)于 TDD 演講中的秘訣是:
編寫紅色測試。解個問題,盡快讓它變綠。設(shè)計一個很好的解決方案,重構(gòu)成你為之驕傲的一個東西。
這里要掌握的一個重要內(nèi)容是,在你的大腦中要分離關(guān)注點。不要試圖同時完成步驟 2 和步驟3。編程的主要限制之一是你的大腦一次能思考多少,并且在你敲代碼時,你需要思考得越少,你寫的代碼越好。
在解決問題時,不要去想代碼實際上應(yīng)該如何。復(fù)制粘貼代碼,寫低效的循環(huán),重復(fù)內(nèi)容,不論是什么只要能盡快讓測試變綠就去做。然后再考慮如何改進。
分離關(guān)注點是首先要測試的原因之一,這種方法有助于實踐中行為。當你不擇手段地想要快速達成一個解決方案時,你不必去考慮它看上去怎么樣或者運行起來快不快。當你進行到完善設(shè)計和改善解決方案的時候,你就不必擔(dān)心解決方法行不通了。
詳詢:王萍老師18988787201
詳詢:小文老師18988787201
王萍老師 | 小文老師 |
《中華考試網(wǎng)軟件測試培訓(xùn)》
《教育軟件測試培訓(xùn)頻道》
《軟件測試培訓(xùn)課程——深圳川石》
《深圳川石軟件性能測試培訓(xùn)》
《深圳川石企業(yè)性能測試(PL&LR)提升班》
《持續(xù)集成自動化測試UFT Selenium提升班》
《深圳源昊寶安軟件測試培訓(xùn)班》
《深圳凌岳軟件自動化測試培訓(xùn)班》
《深圳博睿軟件安全測試培訓(xùn)》
《深圳達內(nèi)軟件測試培訓(xùn)學(xué)?!?/a>