為什么開發(fā)人員不編寫更多測試?
我經(jīng)常在會議上談?wù)? 測試微服務(wù),我問與會者的第一個(gè)問題是他們是否編寫測試。房間通常在為他們的代碼編寫測試的開發(fā)人員和不為他們的代碼編寫測試的開發(fā)人員之間分配 50-50。當(dāng)我在編碼訓(xùn)練營做客座講座時(shí),這種差異變得更加明顯,我發(fā)現(xiàn)只有不到十分之一的畢業(yè)生真正知道如何編寫單元測試。
我的軼事觀察也得到了調(diào)查的支持。Diffblue 發(fā)現(xiàn) 42% 的開發(fā)人員跳過編寫測試,而 Stack Overflow 發(fā)現(xiàn) 37% 的開發(fā)人員不為他們的工作代碼編寫測試。
為了理解為什么開發(fā)人員沒有更好地編寫測試,我決定向幾個(gè)運(yùn)行軟件團(tuán)隊(duì)的朋友提出這個(gè)問題。在這篇文章中,我收集了他們的一些觀察(與我自己的混合),關(guān)于為什么開發(fā)人員沒有像您認(rèn)為的那樣經(jīng)常編寫測試。他們的一些回答讓我感到驚訝,尤其是當(dāng)我們談到今天測試的局限性時(shí)。
最后,我請他們每個(gè)人給我一些提示,給那些可能不熟悉自動化測試的工程領(lǐng)導(dǎo)者和開發(fā)人員。如果你是今天跳過測試的大約 40% 的開發(fā)人員之一,我希望他們的建議能鼓勵(lì)你開始。
反對測試
從廣義上講,自動化測試傾向于提高軟件的可靠性、質(zhì)量和可維護(hù)性。
“如果你對某個(gè)功能進(jìn)行了測試,那么你就會知道未來的一些變化是否會破壞某些東西,” Earthly 的Adam Gordon Bell 告訴我。他補(bǔ)充說,測試是一種動態(tài)的文檔形式:“很多時(shí)候,閱讀測試比閱讀實(shí)際實(shí)現(xiàn)更容易理解某些東西的作用。”
也就是說,編寫測試需要時(shí)間,許多開發(fā)人員沒有(或不能)抽出時(shí)間來編寫它們。隨著代碼庫的增長和測試覆蓋率的不斷下降,這個(gè)問題變得更加明顯。
管理經(jīng)常推出大量功能,而測試總是從優(yōu)先級列表中下滑……一旦您擁有足夠大的代碼庫,您就可以花費(fèi)無限量的時(shí)間來編寫測試,因此可能會令人生畏且難以知道從哪里開始。
如果截止日期很緊或者團(tuán)隊(duì)領(lǐng)導(dǎo)者不是特別致力于測試,這通常是軟件開發(fā)人員被迫跳過的第一件事。
另一方面,一些開發(fā)人員只是認(rèn)為測試不值得他們花時(shí)間。“他們可能會想,‘這是一個(gè)非常小的功能,任何人都可以為此創(chuàng)建一個(gè)測試,我的時(shí)間應(yīng)該在更重要的東西利用。’”的Mudit辛格 LambdaTest告訴我的。
我已經(jīng)看到這種測試態(tài)度在企業(yè)環(huán)境中“低于”開發(fā)人員,在這些環(huán)境中,專門的 QA 團(tuán)隊(duì)可能負(fù)責(zé)大部分測試,但它可能發(fā)生在任何地方。我曾經(jīng)在一家初創(chuàng)公司管理過一位高級開發(fā)人員,他鼓勵(lì)我雇傭初級開發(fā)人員來為他編寫測試。
測試權(quán)衡和限制
所以,你可能認(rèn)為答案很簡單。給開發(fā)人員更多時(shí)間來編寫測試并使其成為他們工作的一部分,對嗎?
事實(shí)上,自動化測試存在一些合理的限制。像軟件開發(fā)中的許多復(fù)雜問題一樣,選擇測試與否是關(guān)于了解權(quán)衡。
“寫自動化測試可以提供信心,您的應(yīng)用程序工作的某些部分如預(yù)期,”首席執(zhí)行官艾丹Cunniff, 光纖告訴我,“但代價(jià)是你已經(jīng)投入了大量的時(shí)間‘穩(wěn)定’,使‘可靠’你系統(tǒng)的那部分。”
我在創(chuàng)業(yè)公司的經(jīng)歷中也看到了這一點(diǎn)。我曾經(jīng)花了三個(gè)星期來構(gòu)建一個(gè)新功能、編寫測試和解決代碼審查,結(jié)果卻被告知業(yè)務(wù)團(tuán)隊(duì)改變了主意,該功能將在下一個(gè) sprint 中刪除。
雖然測試可能使我的新功能更好、更易于維護(hù),但從技術(shù)上講,它們對業(yè)務(wù)來說是浪費(fèi)時(shí)間,因?yàn)樵摴δ懿⒉皇俏覀冋嬲枰摹T陂_始編寫代碼之前,我們沒有投入足夠的時(shí)間來理解問題并制定計(jì)劃。
“想象一下,一群建筑工人和建筑師在一塊空地上與客戶和一大堆木材會面。然后以自發(fā)的方式建造房屋。當(dāng)客戶懷疑地看著完工的房子并抱怨屋頂看起來不太安全時(shí),承包商回答說“別擔(dān)心,我們會等到下雨然后修補(bǔ)漏水的地方。”......沒有其他專業(yè)建造質(zhì)量不受控制的產(chǎn)品然后依靠測試(和缺陷修復(fù))來提高產(chǎn)品質(zhì)量。
最后,某些形式的測試特別難以實(shí)現(xiàn),因?yàn)樗鼈円竽拇a以特定方式編寫。這是對單元測試的常見抱怨。
一方面,單元測試迫使開發(fā)人員以一種“可測試”的方式構(gòu)建他們的代碼,但另一方面,這些單元測試很少告訴你最終的應(yīng)用程序是否為用戶提供了價(jià)值。
在大多數(shù)企業(yè)中,唯一具有業(yè)務(wù)價(jià)值的測試是源自業(yè)務(wù)需求的測試。大多數(shù)單元測試源自程序員對函數(shù)應(yīng)該如何工作的幻想……那些沒有可證明的價(jià)值。
如果您在開始之前沒有單元測試覆蓋率的遺留代碼庫中工作,則幾乎不可能追溯添加它們。因此,大多數(shù)開發(fā)人員轉(zhuǎn)向集成或端到端測試。
這些功能測試可能會有所幫助,但它們也存在問題。任何重要的應(yīng)用程序都會有幾十個(gè)功能和邏輯分支,因此幾乎不可能跟上所有預(yù)期的行為。正如 JB Rainsberger 在他的文章Integrated Tests Are A Scam 中指出的那樣 ,一個(gè)有 20 個(gè)頁面的中型 Web 應(yīng)用程序可能需要 10,000 到 1,000,000 次測試才能涵蓋所有用戶故事。
那么為什么還要嘗試呢?
我認(rèn)為單元測試和特別是測試驅(qū)動的開發(fā)被其支持者過度宣傳為解決所有問題的方法……但是測試,如果做得好,是非常有價(jià)值的。為未來的編寫測試,他們將試圖了解這個(gè)方法在未來的作用。讓自己有信心做出需要做出的改變。
雖然測試不是靈丹妙藥,但當(dāng)它適當(dāng)?shù)貞?yīng)用于手頭的軟件時(shí),它是合法有用的。幾乎在所有情況下,測試對開發(fā)人員來說都是積極的,即使它有局限性。開發(fā)團(tuán)隊(duì)要做的重要事情是有意識地了解他們測試的方式和內(nèi)容。
Aidan Cunniffe 告訴我:“仔細(xì)考慮將測試工作投入到哪里是平衡投資與其提供的價(jià)值的最佳方式。” 跳過對新功能的第一個(gè) alpha 版本的測試可能是合理的,但是“當(dāng)該功能成為其他 3 個(gè)功能的支柱時(shí),就該開始測試了。”
就我個(gè)人而言,我認(rèn)為混合方法是最好的。單元測試對于快速覆蓋大量微小案例很有用,集成測試確保各個(gè)部分按預(yù)期進(jìn)行交互,端到端測試提供用戶界面是否正常工作的最終檢查。
還出現(xiàn)了新的測試品種,試圖減輕我們許多人采用的分層測試方法的一些缺點(diǎn)。例如,我 去年調(diào)查了一些低代碼測試工具,而且還有更多。RelicX首席執(zhí)行官 Sushil Kumar 指出,“使用基于 AI/ML 的測試自動生成測試腳本可以大大減輕開發(fā)人員的負(fù)擔(dān)。”
入門
如果您對辯論如此深入,并且您只是因?yàn)椴淮_定從哪里開始而沒有進(jìn)行測試,那么讓我們談?wù)勀梢詮哪睦镩_始。
最容易開始的地方通常是單元測試。Speedscale 的 Ken Ahrens 告訴我:“當(dāng)你剛開始測試時(shí),弄清楚你的團(tuán)隊(duì)使用什么單元測試框架,并為你的第一次代碼簽入包含一個(gè)單元測試用例。” 繼續(xù)解釋從小做起,但讓測試成為一種習(xí)慣是堅(jiān)持下去的關(guān)鍵。
接下來,您需要獲得團(tuán)隊(duì)其他成員和領(lǐng)導(dǎo)層的支持。需要給開發(fā)人員時(shí)間來編寫測試,并了解這項(xiàng)投資從長遠(yuǎn)來看會得到回報(bào)。
團(tuán)隊(duì)中的每個(gè)人都在編寫測試,或者沒有人在編寫測試,這確實(shí)是一種文化實(shí)踐,一種技術(shù)僵局。沒有人想成為唯一這樣做的人。
證明測試價(jià)值的一種方法是使用它們來防止回歸。“如果某些東西不起作用,”Adam Gordon Bell 告訴我,“在修復(fù)它之前,先編寫一個(gè)功能正確的測試。” 這將降低未來回歸的可能性,并讓您的團(tuán)隊(duì)在將來更新該部分代碼時(shí)充滿信心。
測試有局限性,它們不能替代出色的系統(tǒng)設(shè)計(jì),但測試在軟件開發(fā)中也占有一席之地。給工程師時(shí)間進(jìn)行測試并將測試的價(jià)值傳授給您的團(tuán)隊(duì)是工程領(lǐng)導(dǎo)力的一個(gè)重要角色,而且隨著軟件變得越來越復(fù)雜,它只會變得越來越重要。