測試Vue應(yīng)用程序簡介關(guān)于計(jì)算機(jī)專業(yè)vuex.js介紹概述的畢業(yè)設(shè)計(jì)論文英文英語外文文獻(xiàn)翻譯成品資料（中英文雙語對(duì)照）

本文是中英對(duì)照畢業(yè)設(shè)計(jì)論文外文文獻(xiàn)翻譯，下載后直接可用！省去您找文獻(xiàn)、pdf整理成word以及翻譯的時(shí)間，一輩子也就一次的事！文獻(xiàn)引用作者出處信息:EddYerburghTestingVue.JsApplications,2019(如年份太老，可改為近2年，很多畢業(yè)生都這樣做，畢竟外文翻譯要求也不高)了，可自行刪減，大多數(shù)學(xué)校都是要求選取外文的一部分內(nèi)容進(jìn)行翻譯的。）1.1.DEFININGTESTING1.2.TESTINGOVERVIEW1.3.WRITINGAHACKERNEWSAPPLICATIONHackerNewsclone.components.SUMMARY測試Vue應(yīng)用程序簡介本章將涵蓋什么是測試為什么測試有用單元測試、端對(duì)端測試和快照測試之間的區(qū)別Vue核心概念作為開發(fā)人員，您希望發(fā)布無錯(cuò)誤的代碼。沒有什么比在星期一早上發(fā)現(xiàn)您上周五在應(yīng)用程序上所做的更改中發(fā)現(xiàn)了錯(cuò)誤更糟糕的了！確保應(yīng)用程序正常運(yùn)行的唯一方法是對(duì)其進(jìn)行測試，因此了解如何徹底測試應(yīng)用程序至關(guān)重要。好的測試方法可以加快開發(fā)速度，提高代碼質(zhì)量并限制應(yīng)用程序中的錯(cuò)誤。不良的測試方法會(huì)使項(xiàng)目癱瘓。本章將教您有效地測試Vue應(yīng)用程序，以確保獲得良好的測試效果并避免漏洞。到本書結(jié)尾時(shí)，您將成為Vue測試的高手，可以測試遇到的任何Vue應(yīng)用程序。要學(xué)習(xí)測試Vue應(yīng)用程序的技術(shù)，您將要從頭到尾編寫一個(gè)針對(duì)HackerNews克隆的測試套件。就像大多數(shù)大型Vue應(yīng)用程序一樣，HackerNews應(yīng)用程序?qū)⑹褂肰ue、Vuex、VueRouter和服務(wù)器端渲染。除了教給您技術(shù)之外，我還想教給您我多年來開發(fā)的心態(tài)和測試方法。在整本書中，我會(huì)為您提供一些磨練測試技能的建議。第一章是測試Vue應(yīng)用程序的入門。我將為您提供測試的總體概述，本章你將學(xué)習(xí)到各種測試類型以及您將編寫HackerNews應(yīng)用。最后，我將解釋一些Vue核心概念，以確保我們使用的術(shù)語相同。首先要做的是定義測試。任何值得一提的學(xué)術(shù)論文都會(huì)在深入討論它們之前定義其使用的概念。因此，就像一位優(yōu)秀的學(xué)者一樣，在向您介紹不同的測試技術(shù)之前，我將通過測試應(yīng)用程序來定義我要表達(dá)的意思。一個(gè)簡單的定義是，測試應(yīng)用程序是檢查應(yīng)用程序運(yùn)行是否正確的過程。毫無疑問，您應(yīng)該驗(yàn)證應(yīng)用程序的運(yùn)行是否正確，但是當(dāng)您談?wù)摬煌臏y試技術(shù)時(shí)，該主題會(huì)變得更加有趣。有兩種主要的測試方法：手動(dòng)測試和自動(dòng)測試。手動(dòng)測試是通過自己與應(yīng)用程序進(jìn)行交互來檢查應(yīng)用程序是否能正常工作。自動(dòng)化測試是編寫程序?yàn)槟鷪?zhí)行測試的一種做法。本章大部分內(nèi)容是關(guān)于自動(dòng)化測試的。但是要了解自動(dòng)化測試的好處，您需要了解手動(dòng)測試。每個(gè)可雇用的開發(fā)人員都要手動(dòng)測試代碼。這是編寫源代碼之后的下一個(gè)邏輯步驟，例如咀嚼食物后如何將其吞下。假設(shè)您要?jiǎng)?chuàng)建一個(gè)注冊(cè)表單。完成編寫代碼后，您不僅會(huì)關(guān)閉文本編輯器，并告訴老板您已經(jīng)完成了表單。不，您將打開瀏覽器，填寫表格，并確保它正確完成了注冊(cè)過程。換句話說，您將手動(dòng)測試代碼。手動(dòng)測試非常適合小型項(xiàng)目。如果您有TODO清單應(yīng)用程序，可以在兩分鐘內(nèi)手動(dòng)檢查，則無需進(jìn)行自動(dòng)測試。但是，當(dāng)您的應(yīng)用增長到一定大小時(shí)，依靠手動(dòng)測試就成為一種負(fù)擔(dān)。讓我告訴您有關(guān)我工作的第一個(gè)大型JavaScript應(yīng)用程序的信息。該應(yīng)用程序一團(tuán)糟。您聽說過意大利面代碼嗎？該代碼是將意大利面條，意大利面條和意大利面條代碼合二為一的。遵循應(yīng)用程序邏輯非常困難，并且沒有任何自動(dòng)化測試。不用說，代碼中有bug。為了阻止錯(cuò)誤，我們將在發(fā)布應(yīng)用程序之前對(duì)其進(jìn)行手動(dòng)測試。每個(gè)星期三，我們都會(huì)倒咖啡，打開用戶測試旅程清單，并彎腰筆記本電腦四個(gè)小時(shí)，以完成這組說明。真痛苦考慮到我們花了10％的開發(fā)時(shí)間來手動(dòng)測試該應(yīng)用程序，您可能會(huì)以為我們會(huì)停止將任何bug投入生產(chǎn)。不。該應(yīng)用程序充滿了他們。原因是手動(dòng)測試數(shù)百個(gè)功能很困難-太容易失去專心而忘記檢查某些東西。有一次，在進(jìn)行用戶旅程時(shí)，我不小心忘記了單擊一下按鈕是否會(huì)顯示音樂曲目的元數(shù)據(jù)。其他開發(fā)人員一定也忘記測試該功能，因?yàn)樵撳e(cuò)誤已經(jīng)存在了幾個(gè)月！盡管我們的一些手動(dòng)測試時(shí)間花在了測試新功能上，但大多數(shù)人還是花了測試舊功能來檢查它們是否仍然有效。這種測試稱為回歸測試?；貧w測試對(duì)于我們?nèi)祟悂碚f是一項(xiàng)艱巨的任務(wù)-它們是重復(fù)性的，需要大量關(guān)注，并且沒有創(chuàng)造性的投入。簡而言之，它們很無聊。幸運(yùn)的是，計(jì)算機(jī)可以勝任這些任務(wù)，而這正是自動(dòng)化測試的用武之地！自動(dòng)化測試是使用程序檢查軟件是否正常運(yùn)行的過程。換句話說，您編寫了額外的代碼來測試您的應(yīng)用程序代碼。編寫測試代碼后，您可以輕松進(jìn)行任意多次測您可以使用許多不同的技術(shù)來編寫自動(dòng)化測試。您可以編寫程序來自動(dòng)化瀏覽器，直接在源代碼中調(diào)用函數(shù)，或者比較渲染的應(yīng)用程序的屏幕截圖。每種技術(shù)都有不同的優(yōu)點(diǎn)，但是它們都有一些共同點(diǎn)：與手動(dòng)測試相比，它們可以節(jié)省您的時(shí)在上一節(jié)中，我談到了一個(gè)未經(jīng)測試的應(yīng)用程序。該應(yīng)用程序的問題之一是，每次我們要發(fā)布該應(yīng)用程序的新版本時(shí)，我們都要進(jìn)行四個(gè)小時(shí)的手動(dòng)測試。我加入團(tuán)隊(duì)后不久，CTO決定我們應(yīng)該編寫自動(dòng)化測試來為我們完成這項(xiàng)工作。隨著時(shí)間的流逝，我們將測試時(shí)間從四個(gè)小時(shí)的手動(dòng)工作減少到20分鐘的自動(dòng)工作。積累了這些經(jīng)驗(yàn)之后，我從一開始就一直為大型項(xiàng)目編寫自動(dòng)化測試。馴養(yǎng)一匹與人類同生的馬匹要比馴服野馬要容易得多。在本書中，您將學(xué)習(xí)根據(jù)應(yīng)用程序的概念編寫測試來創(chuàng)建馴服應(yīng)用程序。自動(dòng)化測試非常適合檢查您的應(yīng)用程序是否仍然有效。它們還使查看應(yīng)用程序的代碼更改更加容易。讓我們看一下使用自動(dòng)化測試的真實(shí)示例-在GitHub上測試請(qǐng)求請(qǐng)求。GitHub是一個(gè)托管Git存儲(chǔ)庫的網(wǎng)站。Vue等許多開源項(xiàng)目都托管在GitHub上，而我工作的大多數(shù)公司都將其代碼保存在私有GitHub存儲(chǔ)庫中。如果沒有測試，則在查看拉取請(qǐng)求時(shí)，需要將代碼更改拉到計(jì)算機(jī)上，運(yùn)行應(yīng)用程序，然后手動(dòng)測試代碼以驗(yàn)證其是否仍然有效。這很耗時(shí)，當(dāng)聽到某些人在審核請(qǐng)求請(qǐng)求時(shí)完全跳過此過程時(shí)，您不會(huì)感到驚訝。自動(dòng)化測試使此過程變得更加容易。在項(xiàng)目中進(jìn)行自動(dòng)化測試后，可以設(shè)置服務(wù)來下載拉取請(qǐng)求分支，運(yùn)行測試套件并報(bào)告測試是否通過（圖1.1）。只要您信任測試，就無需在自己的計(jì)算機(jī)上檢查代碼。大多數(shù)開源項(xiàng)目要求開發(fā)人員在添加新功能時(shí)編寫新測試。Vue僅接受包含測試新代碼的拉取請(qǐng)求。除了使拉取請(qǐng)求更易于審核之外，自動(dòng)化測試還使現(xiàn)代化的工作流程（如持續(xù)集成和持續(xù)交付）成為可能。如果您對(duì)這些工作流程感興趣，可以在MartinFowler的博客（http://mng.bz/nxVK）上閱讀有關(guān)它們的信息?，F(xiàn)在，我已經(jīng)定義了自動(dòng)測試和手動(dòng)測試，是時(shí)候更具體了。下一節(jié)概述了自動(dòng)測試技術(shù)，以及如何使用它們來檢查應(yīng)用程序。到目前為止，我已經(jīng)談到了高級(jí)測試?，F(xiàn)在該討論您可以編寫的特定測試類型。在本書中，您將學(xué)習(xí)為前端應(yīng)用程序編寫三種類型的測試：單元測試，快照測試和端到端測試。端到端測試是最直觀的測試類型。在前端應(yīng)用程序中，端到端測試使瀏覽器自動(dòng)化，以從用戶的角度檢查應(yīng)用程序是否正常運(yùn)行。假設(shè)您正在編寫一個(gè)計(jì)算器應(yīng)用程序，并且要測試它是否正確地將兩個(gè)數(shù)字相加。您可以編寫一個(gè)端到端測試，以打開瀏覽器，加載計(jì)算器應(yīng)用，單擊1按鈕，單擊加號(hào)（+）按鈕，再次單擊1按鈕，單擊等于（=）并檢查屏幕顯示正確的結(jié)果（2）。在下一個(gè)清單中，您可以看到一個(gè)示例代碼。1在瀏覽器中導(dǎo)航到本地運(yùn)行的應(yīng)用程序2單擊計(jì)算器按鈕3斷言計(jì)算器顯示正確的結(jié)果端到端測試可以節(jié)省大量時(shí)間。編寫完端到端測試后，可以根據(jù)需要多次運(yùn)行它。想象一下，一套數(shù)百種這樣的測試可以節(jié)省多少時(shí)間！首先，端到端測試似乎是您唯一需要的測試工具。但是它們有一些問題。首先，端到端測試很慢。啟動(dòng)瀏覽器可能需要幾秒鐘，并且網(wǎng)站響應(yīng)速度可能很慢。一組端到端測試通常需要30分鐘才能運(yùn)行，并且如果您完全依靠端到端測試，那么您的測試套件將需要花費(fèi)數(shù)小時(shí)才能運(yùn)行。端到端測試的另一個(gè)問題是調(diào)試它們可能很困難。要調(diào)試端到端測試，您需要打開瀏覽器并逐步完成用戶過程以自己重現(xiàn)該錯(cuò)誤。當(dāng)您在本地運(yùn)行端到端測試時(shí)，這已經(jīng)很糟糕了，但是如果您的測試在CI服務(wù)器上失敗，而不是在本地計(jì)算機(jī)上失敗，那么您的日子將會(huì)很糟糕。端到端測試還有另一個(gè)問題-它們可能很不穩(wěn)定。不穩(wěn)定測試是即使測試的應(yīng)用程序正在運(yùn)行也經(jīng)常失敗的測試。也許代碼執(zhí)行時(shí)間太長，或者API暫時(shí)關(guān)閉。就像片狀的朋友一樣，您將不再認(rèn)真地對(duì)待片狀的測試?！芭?，不，測試失敗了！讓我看看。。。。哦，就是那個(gè)。一個(gè)人一直失的測試會(huì)使您的測試套件失去用處，但是在編寫端到端測試時(shí)很難避免！如果您列出了開發(fā)人員所抱怨的所有內(nèi)容，那么我將把錢花在排名前三的端到端測試中。盡管它們很有用，但它們不應(yīng)該是您唯一的測試類型。在本書中，只有一章專門用于端到端測試，部分原因是端到端測試的缺點(diǎn)，部分原因是端到端測試與框架無關(guān)，無論您的應(yīng)用程序是否編寫，它們都可以工作使用Vue或MooTools。端到端測試使您可以手動(dòng)執(zhí)行的測試自動(dòng)化。您可以將它們?cè)O(shè)置為定期在實(shí)時(shí)網(wǎng)站上運(yùn)行，也可以在合并到master分支之前針對(duì)代碼運(yùn)行它們。端到端測試并沒有為您提供一種測試代碼的新方法-您可以獲得更快的手動(dòng)測試。另一方面，單元測試為您提供了一種新工具，您無法通過手動(dòng)測試代碼獲得該工具。單元測試是針對(duì)應(yīng)用程序的最小部分（單元）運(yùn)行測試的過程。通常，您要測試的單元是功能，但在Vue應(yīng)用程序中，組件也是要測試的單元（稍后將進(jìn)一步介紹）。還記得計(jì)算器應(yīng)用程序嗎？在代碼中，應(yīng)用程序使用求和函數(shù)來計(jì)算兩個(gè)數(shù)字的和。如果您編輯了該功能以使其易于閱讀，則需要測試該功能是否仍可正常工作。您可以運(yùn)行端到端測試，但是如果端到端測試失敗，您將不知道問題是出在sum函數(shù)還是源代碼的其他部分。您可以確定的唯一原因就是破壞了sum函數(shù)，那就是單獨(dú)運(yùn)行該函數(shù)。您可以通過單元測試來做到這一點(diǎn)。單元測試是在源代碼中單獨(dú)調(diào)用函數(shù)并斷言它們行為正確的函數(shù)?？纯聪乱粋€(gè)清單。這是一個(gè)簡單的程序，可導(dǎo)入求和函數(shù)，運(yùn)行該函數(shù)，如果sum不返回2，則會(huì)引發(fā)錯(cuò)誤。2將求和函數(shù)導(dǎo)入測試文件3如果總和不返回，將引發(fā)錯(cuò)誤24運(yùn)行測試因?yàn)閱卧獪y試是針對(duì)隔離的單元運(yùn)行的，所以當(dāng)編寫良好的單元測試失敗時(shí)，它就像是閃爍的霓虹燈，將您引向問題代碼。與端到端測試不同，單元測試是快速的。它們會(huì)在幾秒鐘內(nèi)運(yùn)行，因此您每次進(jìn)行代碼更改時(shí)都可以運(yùn)行單元測試，以快速獲得有關(guān)更改是否破壞現(xiàn)有功能的反單元測試的一個(gè)令人愉快的副作用是它們提供了文檔。如果新開發(fā)人員開始一個(gè)項(xiàng)目并且需要知道代碼單元的行為方式，則他們可以查看測試以確切了解單元的行為方式。我之前談到過不穩(wěn)定的端到端測試，這些測試即使應(yīng)用程序運(yùn)行正常也經(jīng)常失敗。編寫良好的單元測試不會(huì)遇到這個(gè)問題。只要單元測試是確定性的，您就可以運(yùn)行一千次，并且每次都會(huì)通過。到目前為止，關(guān)于單元測試，我只能說些好話了，我正在使它們臉紅。但是我不想誤導(dǎo)你。像端到端測試一樣，單元測試也有其自身的問題。單元測試的一個(gè)大問題是它們使重構(gòu)代碼變得困難。如果您具有帶有單元測試的復(fù)雜功能，并決定將功能拆分為兩個(gè)單獨(dú)的功能，則需要更改單元測試以及代碼。這會(huì)使重構(gòu)的吸引力大大降低。有時(shí)我不愿更改代碼的結(jié)構(gòu)，因?yàn)楦聠卧獪y試需要大量的額外工作。這里沒有一個(gè)簡單的解決方案，但是當(dāng)您決定編寫的測試是否可以長期節(jié)省您的時(shí)間時(shí)，還需要考慮一些其他事項(xiàng)。單元測試的另一個(gè)問題是它們僅檢查應(yīng)用程序的各個(gè)部分。您可以測試汽車的各個(gè)部分是否正常工作，但是如果不檢查它們?cè)谘b配在一起后是否正常工作，然后發(fā)動(dòng)機(jī)沒有打開，則測試無效。單元測試遭受這個(gè)問題。他們可以確保代碼單元的行為符合預(yù)期，但不能測試這些單元之間是否可以正確交互。因此，您需要使用端到端測試來補(bǔ)充單元測試。到目前為止，我已經(jīng)為您提供了端到端測試和單元測試的概述。您將在本書中學(xué)習(xí)的最終測試是快照測試。你玩過《發(fā)現(xiàn)差異》嗎？“發(fā)現(xiàn)差異”是一款游戲，您擁有兩張相同的圖片，但它們之間的差異很小。游戲的目的是識(shí)別差異?？煺諟y試類似于“發(fā)現(xiàn)差異”?？煺諟y試會(huì)為您正在運(yùn)行的應(yīng)用程序拍照，并將其與以前保存的圖片進(jìn)行比較。如果圖片不同，則測試失敗。此測試方法是確保應(yīng)用程序在代碼更改后繼續(xù)正確呈現(xiàn)的有用方法。傳統(tǒng)的快照測試會(huì)在瀏覽器中啟動(dòng)應(yīng)用程序，并對(duì)呈現(xiàn)的頁面進(jìn)行截圖。他們會(huì)將新拍攝的屏幕截圖與保存的屏幕截圖進(jìn)行比較，如果存在差異，則會(huì)顯示錯(cuò)誤。當(dāng)操作系統(tǒng)或?yàn)g覽器版本之間的差異導(dǎo)致測試失?。词箍煺瘴锤模r(shí)，此類快照測試也會(huì)出現(xiàn)問題。在本書中，我將教您如何使用Jest測試框架編寫快照測試。Jest快照測試可以比較JavaScript中的任何可序列化的值，而不是比較屏幕截圖。您可以使用它們來比較Vue組件的DOM輸出。您將在第12章中詳細(xì)了解快照測試?，F(xiàn)在，您已經(jīng)看到了要編寫的每種測試類型?，F(xiàn)在該討論如何組合這些不同的測試類型以編寫有效的測試套件。如果將糖，面粉和黃油的混合量正確混合，則會(huì)得到美味的曲奇面團(tuán)。如果使用錯(cuò)誤的數(shù)量，則會(huì)得到面粉。您需要以正確的數(shù)量將不同類型的測試組合在一起，以確保您擁有一個(gè)強(qiáng)大的測試套件，而不是一堆測試代碼。金字塔的大部分都包含單元測試-它們?cè)陂_發(fā)應(yīng)用程序時(shí)提供快速反饋?？煺諟y試也可以快速運(yùn)行，但是覆蓋范圍比單元測試要多，因此您不需要像單元測試一樣多的快照測試。如果您是經(jīng)驗(yàn)豐富的開發(fā)人員，則可能聽說過集成測試。集成測試是另一種類型的測試，通常與單元測試和端到端測試結(jié)合使用。我不建議為前端代碼編寫集成測試。前端的集成測試很難定義，編寫和調(diào)試。人們對(duì)集成測試的定義有所不同，尤其是在前端。一些人認(rèn)為在瀏覽器環(huán)境中運(yùn)行的測試是集成測試。有些人認(rèn)為任何測試具有模塊依賴性的單元的測試都是集成測試。有人認(rèn)為任何完全渲染的組件都是集成測試。在第13章中，我將教您如何編寫服務(wù)器端集成測試（使用我自己的定義以確保服務(wù)器以正確的HTTP請(qǐng)求進(jìn)行響應(yīng)。但是對(duì)于本書中的前端測試，您不會(huì)編寫任何集成測試。在現(xiàn)實(shí)生活中，有時(shí)我不為組件編寫單元測試，有時(shí)在編寫測試之前編寫組件代碼。TDD倡導(dǎo)者可能會(huì)驚恐地cl住自己的臉，但我發(fā)現(xiàn)對(duì)TDD采取僵化的方法會(huì)減緩發(fā)展。俗話說，生命是旅程，而不是目的地。盡管總的來說，這可能是正確的，但在開發(fā)應(yīng)用程序的情況下卻相反。只要編寫節(jié)省時(shí)間的有價(jià)值的測試，編寫它們的方式就無關(guān)緊要。對(duì)于本書的大部分內(nèi)容，我都會(huì)告訴您要測試的內(nèi)容，向您展示測試代碼，然后向您展示可以通過測試的源代碼。在添加以下源代碼之前，運(yùn)行測試時(shí)預(yù)期測試將失敗。到目前為止，我已經(jīng)向您介紹了自動(dòng)化測試的好處，但是在您過度興奮并創(chuàng)建一個(gè)自動(dòng)化測試贊賞協(xié)會(huì)之前，有一個(gè)免責(zé)聲明。自動(dòng)化測試并非總是必要的。當(dāng)我開始編寫自動(dòng)化測試時(shí)，我想測試所有東西。我親身經(jīng)歷了未經(jīng)測試的應(yīng)用程序所帶來的痛苦，并且像一個(gè)宿醉的中年男人一樣，我下定決心不要再這樣做了。但是我很快又吸取了教訓(xùn)。測試會(huì)減慢開發(fā)速度。編寫測試時(shí)，請(qǐng)務(wù)必記住編寫測試的原因。通常，測試的目的是節(jié)省時(shí)間。如果您正在從事的項(xiàng)目很穩(wěn)定并且可以長期開發(fā)，那么測試會(huì)帶來回報(bào)。但是，如果編寫和維護(hù)測試所花的時(shí)間比保存您的時(shí)間長，那么您根本不應(yīng)該編寫測試。當(dāng)然，在編寫代碼之前很難知道通過進(jìn)行測試可以節(jié)省多少時(shí)間-隨著時(shí)間的推移會(huì)學(xué)到這一點(diǎn)-但是例如，如果您要?jiǎng)?chuàng)建原型，從事短期項(xiàng)目，或在一家初創(chuàng)公司迭代一個(gè)想法，您可能不會(huì)從編寫測試中受益。即使項(xiàng)目受益于測試，它可能也不需要您想像的那么多測試。讓我告訴您有關(guān)100％代碼覆蓋率的謬誤。代碼覆蓋率是對(duì)自動(dòng)化測試運(yùn)行代碼庫中多少行的度量。通常，代碼覆蓋率以百分比衡量：100％的代碼覆蓋率表示在測試執(zhí)行過程中每行代碼都會(huì)運(yùn)行；0%的代碼覆蓋率意味著不執(zhí)行任何行。這是一個(gè)有趣的測量，但可能會(huì)導(dǎo)致一些可怕的后果。測試提供的收益遞減。這就像去健身房。初次去健身房時(shí)，您會(huì)迅速建立肌肉。每周只有三個(gè)小時(shí)的健身，幾個(gè)月后，您可能會(huì)失去啤酒肚，看起來看起來很健美。但是，您獲得的越大，則成長所需的時(shí)間就越多。您在健身房花費(fèi)的時(shí)間越長，每增加一小時(shí)所獲得的收益就越少。相同的原則適用于測試。您可以在幾個(gè)小時(shí)內(nèi)編寫涵蓋應(yīng)用程序核心功能的簡單測試。編寫完這些測試后，增加代碼覆蓋率將變得越來越困難。如果您希望100%的代碼覆蓋率（對(duì)于某些開發(fā)人員來說是圣杯那將像用毛巾擰干最后一滴水一樣。辛苦了在大多數(shù)情況下，100％的代碼覆蓋率并不是目標(biāo)。當(dāng)然，如果您正在開發(fā)任務(wù)關(guān)鍵型支付應(yīng)用程序，其中的錯(cuò)誤可能造成數(shù)百萬美元的損失，那么100％的代碼覆蓋率將使您受益。但是根據(jù)我的經(jīng)驗(yàn)，大多數(shù)應(yīng)用程序都無法從100％的代碼覆蓋率中受益。在過去的幾年中