關(guān)于類型化JavaScript的價(jià)值，時(shí)不時(shí)就會出現(xiàn)一場辯論?！岸鄬懶y試！”一些反對者喊道。“用類型替換單元測試！”其他人大聲疾呼。兩者在某些方面是對的，在另一些方面是錯(cuò)的。Twitter的空間不足以體現(xiàn)細(xì)微之處。但在本文中，我們可以嘗試闡述一個(gè)合理的論點(diǎn)，說明兩者如何以及應(yīng)該如何共存。

正確性：我們真正想要的

最好從結(jié)果開始。我們從所有這些元工程最終真正想要的是正確性。我不是指嚴(yán)格的理論計(jì)算機(jī)科學(xué)定義，而是程序行為與其規(guī)范的更普遍的遵守：我們腦海中對程序的工作方式有一個(gè)想法，而編程過程則組織位和字節(jié)，使這個(gè)想法成為現(xiàn)實(shí)。因?yàn)槲覀儾⒉豢偸蔷_地知道我們想要什么，而且我們希望確信我們的程序在進(jìn)行更改時(shí)不會中斷，所以我們在現(xiàn)有的原始代碼之上編寫類型和測試，僅僅是為了讓事情首先能夠工作。

因此，如果我們接受正確性是我們想要的，而類型和測試只是實(shí)現(xiàn)這一目標(biāo)的自動(dòng)化方法，那么最好有一個(gè)直觀的模型來展示類型和測試如何幫助我們實(shí)現(xiàn)正確性，從而理解它們在哪里重疊以及在哪里相互補(bǔ)充。

程序正確性的可視化模型

如果我們將程序可能執(zhí)行的所有操作（包括錯(cuò)誤）的整個(gè)無限圖靈完備可能空間想象為一個(gè)巨大的灰色區(qū)域，那么我們希望程序執(zhí)行的操作，我們的規(guī)范，是該可能空間的一個(gè)非常非常小的子集（下圖中的綠色菱形，為了顯示某些內(nèi)容而夸大了大小）：

我們在編程中的工作是盡可能地將我們的程序與規(guī)范協(xié)調(diào)一致（當(dāng)然，我們知道我們是不完美的，我們的規(guī)范不斷變化，例如由于人為錯(cuò)誤、新功能或未指定的行為；因此我們從未完全設(shè)法實(shí)現(xiàn)完全重疊）：

再次注意，為了我們在此處的討論目的，程序行為的邊界也包括計(jì)劃中和計(jì)劃外的錯(cuò)誤。我們對“正確性”的含義包括計(jì)劃中的錯(cuò)誤，但不包括計(jì)劃外的錯(cuò)誤。

測試與正確性

我們編寫測試以確保我們的程序符合我們的期望，但有許多需要測試的內(nèi)容的選擇：

理想的測試是圖中的橙色點(diǎn)——它們準(zhǔn)確地測試了我們的程序是否與規(guī)范重疊。在這個(gè)可視化中，我們并沒有真正區(qū)分測試類型，但您可以將單元測試想象成非常小的點(diǎn)，而集成/端到端測試是大的點(diǎn)。無論哪種方式，它們都是點(diǎn)，因?yàn)闆]有一個(gè)測試可以完全描述程序中的每條路徑。（事實(shí)上，您可以擁有100%的代碼覆蓋率，但仍然無法測試每條路徑，因?yàn)榇嬖诮M合爆炸?。?/p>

圖中的藍(lán)色點(diǎn)是一個(gè)糟糕的測試。當(dāng)然，它測試了我們的程序是否有效，但它實(shí)際上并沒有將其固定到底層規(guī)范（歸根結(jié)底，我們真正想要從程序中獲得的東西）。當(dāng)我們修復(fù)程序以更緊密地與規(guī)范對齊時(shí)，此測試就會中斷，給我們一個(gè)誤報(bào)。

紫色點(diǎn)是一個(gè)有價(jià)值的測試，因?yàn)樗鼫y試了我們認(rèn)為程序應(yīng)該如何工作，并確定了程序當(dāng)前沒有工作的區(qū)域。領(lǐng)先使用紫色測試并相應(yīng)地修復(fù)程序?qū)崿F(xiàn)也被稱為測試驅(qū)動(dòng)開發(fā)。

圖中的紅色測試是一個(gè)罕見的測試。它不是測試“快樂路徑”（包括計(jì)劃的錯(cuò)誤狀態(tài)）的普通（橙色）測試，而是一個(gè)期望并驗(yàn)證“不快樂路徑”失敗的測試。如果此測試在應(yīng)該“失敗”的地方“通過”，則這是一個(gè)巨大的早期警告信號，表明出了問題——但編寫足夠的測試來覆蓋規(guī)范綠色區(qū)域之外存在的巨大可能的不快樂路徑基本上是不可能的。人們很少發(fā)現(xiàn)測試那些不應(yīng)該工作的東西不工作有價(jià)值，所以他們不做；但當(dāng)事情出錯(cuò)時(shí)，它仍然可以是一個(gè)有幫助的早期警告信號。

類型與正確性

如果測試是程序可能執(zhí)行操作的可能性空間上的單個(gè)點(diǎn)，則類型表示從總可能性空間中分割整個(gè)部分的類別。我們可以將它們可視化為矩形：

我們選擇一個(gè)矩形來對比表示程序的菱形，因?yàn)闆]有一個(gè)類型系統(tǒng)本身可以使用類型來完全描述我們的程序行為。（要舉一個(gè)簡單的例子，一個(gè)應(yīng)該始終為正整數(shù)的id是一個(gè)數(shù)字類型，但數(shù)字類型也接受分?jǐn)?shù)和負(fù)數(shù)。除了非常簡單的數(shù)字文字聯(lián)合之外，無法將數(shù)字類型限制在特定范圍內(nèi)。）

類型在您編寫代碼時(shí)充當(dāng)程序可以運(yùn)行位置的約束。如果我們的程序開始超過程序類型的指定邊界，我們的類型檢查器（如TypeScript或Flow）將簡單地拒絕讓我們編譯程序。這很好，因?yàn)樵谙馢avaScript這樣的動(dòng)態(tài)語言中，很容易意外地創(chuàng)建一個(gè)肯定不是您想要?jiǎng)?chuàng)建的崩潰程序。最簡單的附加值是自動(dòng)空值檢查。如果foo沒有名為bar的方法，則調(diào)用foo.bar()將導(dǎo)致眾所周知的undefined is not a function運(yùn)行時(shí)異常。如果foo被完全類型化，則可以在編寫時(shí)由類型檢查器捕獲此問題，并具體指出有問題的代碼行（并具有自動(dòng)完成的伴隨好處）。這是測試根本無法做到的事情。

我們可能希望為我們的程序編寫嚴(yán)格的類型，就好像我們試圖編寫仍然符合我們規(guī)范的盡可能小的矩形一樣。但是，這有一個(gè)學(xué)習(xí)曲線，因?yàn)槌浞掷妙愋拖到y(tǒng)涉及學(xué)習(xí)全新的語法和運(yùn)算符以及泛型類型邏輯的語法，這些語法和邏輯是模擬JavaScript的完整動(dòng)態(tài)范圍所必需的。手冊和備忘單有助于降低學(xué)習(xí)曲線，并且這里需要更多投資。

幸運(yùn)的是，這個(gè)采用/學(xué)習(xí)曲線不必阻止我們。由于類型檢查是Flow的可選過程，并且TypeScript的可配置嚴(yán)格性（能夠選擇性地忽略有問題的代碼行），我們可以從類型安全的范圍內(nèi)進(jìn)行選擇。我們甚至可以對此進(jìn)行建模：

較大的矩形，如上圖中的大紅色矩形，表示對代碼庫的類型系統(tǒng)的非常寬松的采用——例如，允許implicitAny并完全依賴類型推斷來僅僅將我們的程序從最糟糕的編碼中限制出來。

中等嚴(yán)格性（如中等大小的綠色矩形）可以表示更忠實(shí)的類型化，但有很多漏洞，例如在整個(gè)代碼庫中使用顯式any實(shí)例和手動(dòng)類型斷言。盡管如此，即使進(jìn)行這種輕量級的類型化工作，與我們的規(guī)范不匹配的有效程序的可能表面積也會大大減少。

最大嚴(yán)格性，如紫色矩形，使事情與我們的規(guī)范非常緊密，以至于它有時(shí)會發(fā)現(xiàn)您的程序中不符合的部分（這些通常是程序行為中計(jì)劃外的錯(cuò)誤）。像這樣在現(xiàn)有程序中查找錯(cuò)誤是將普通JavaScript代碼庫轉(zhuǎn)換的團(tuán)隊(duì)中非常常見的案例。但是，從我們的類型檢查器中獲得最大的類型安全性可能需要利用泛型類型和特殊運(yùn)算符，這些運(yùn)算符旨在為每個(gè)變量和函數(shù)細(xì)化和縮小可能的類型空間。

請注意，我們不必在編寫類型之前先編寫程序。畢竟，我們只是希望我們的類型能夠密切模擬我們的規(guī)范，因此我們實(shí)際上可以先編寫我們的類型，然后稍后再填充實(shí)現(xiàn)。理論上，這將是類型驅(qū)動(dòng)開發(fā)；在實(shí)踐中，很少有人真正以這種方式開發(fā)，因?yàn)轭愋团c我們的實(shí)際程序代碼緊密地滲透和交織在一起。

將它們放在一起

我們最終要建立的是一個(gè)直觀的可視化，說明類型和測試如何在保證程序的正確性方面相互補(bǔ)充。

我們的測試斷言我們的程序在選定的關(guān)鍵路徑中專門按預(yù)期執(zhí)行（盡管如上所述，存在某些其他測試變體，但絕大多數(shù)測試都這樣做）。在我們已經(jīng)開發(fā)的可視化語言中，它們將程序的深綠色菱形“固定”到規(guī)范的淺綠色菱形上。程序的任何移動(dòng)都會破壞這些測試，這會使它們發(fā)出警報(bào)。這很棒！測試也具有無限的靈活性和可配置性，適用于最自定義的用例。

我們的類型斷言我們的程序不會脫離我們的控制，方法是禁止超出我們繪制的邊界的可能故障模式，希望盡可能緊密地圍繞我們的規(guī)范。在我們可視化語言中，它們“包含”程序偏離規(guī)范的可能漂移（因?yàn)槲覀兛偸谴嬖谌毕?，我們犯的每一個(gè)錯(cuò)誤都會為我們的程序增加額外的失敗行為）。類型也是鈍的，但功能強(qiáng)大的（因?yàn)轭愋屯茢嗪途庉嬈鞴ぞ撸┕ぞ?，受益于?qiáng)大的社區(qū)提供的您不必從頭開始編寫的類型。

簡而言之：

• 測試最擅長確保快樂路徑有效。
• 類型最擅長防止不快樂路徑存在。

根據(jù)它們的優(yōu)勢將它們一起使用，以獲得最佳結(jié)果！

如果您想了解更多關(guān)于類型和測試如何交叉的信息，Gary Bernhardt關(guān)于邊界的精彩演講和Kent C. Dodds的測試獎(jiǎng)杯對我的這篇文章的思考產(chǎn)生了重大影響。

以上是類型或測試：為什么不呢？的詳細(xì)內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！