#在上一篇文章中，我們開始討論 WordPress 中的單元測(cè)試?yán)碚?。具體來說，我們回顧了我們?cè)趩卧獪y(cè)試主題和插件方面的工作，然後開始討論程式碼單元，這如何影響我們的測(cè)試，並且我們回顧了更大的軟體開發(fā)世界中的單元測(cè)試。

我們將繼續(xù)討論 WordPress 中的單元測(cè)試?yán)碚?，但?huì)從它如何幫助識(shí)別問題、驅(qū)動(dòng)架構(gòu)、記錄專案等角度進(jìn)行討論。

發(fā)現(xiàn)問題，節(jié)省時(shí)間

回想一下本系列前面的內(nèi)容，進(jìn)行單元測(cè)試的傳統(tǒng)方法是這樣的：

• 寫測(cè)試，運(yùn)行它（知道它會(huì)失?。?/li>
• 編寫函數(shù)以使該方法通過。
• 運(yùn)行測(cè)試。如果測(cè)試失敗，則繼續(xù)處理該功能；否則，請(qǐng)轉(zhuǎn)到下一個(gè)。

是的，第一步有點(diǎn)教條。為什麼要浪費(fèi)時(shí)間去運(yùn)行一些你知道會(huì)失敗的東西，對(duì)吧？不過，你明白了。但是當(dāng)您開始將這種特殊技術(shù)應(yīng)用於開發(fā)時(shí)，您會(huì)發(fā)現(xiàn)編寫程式碼時(shí)會(huì)形成一定的節(jié)奏，而這是整個(gè)目標(biāo)的一部分。

但這只是其中的一半——單元測(cè)試實(shí)際上可以幫助您在開發(fā)早期發(fā)現(xiàn)問題。

為了理解這一點(diǎn)，最好回顧一下這個(gè)想法。

假設(shè)您正在為基於 WordPress 的專案開發(fā)一項(xiàng)功能，您將允許使用者在不實(shí)際登入 WordPress 儀表板的情況下建立使用者帳戶。這假設(shè)您已經(jīng)設(shè)定了一個(gè)頁(yè)面範(fàn)本來處理註冊(cè)、必要的驗(yàn)證以及用於產(chǎn)生密碼和電子郵件的程式碼。

您在瀏覽器中載入頁(yè)面，嘗試建立一些使用者 - 一些具有相同的電子郵件地址，有些具有不正確的密碼，有些具有非法字元等。您明白了 - 有多種方法驗(yàn)證通過和失敗。這太粗糙了吧！這表示每次變更使用者註冊(cè)功能時(shí)，您都必須執(zhí)行相同的 n 次註冊(cè)，以確保不會(huì)出現(xiàn)任何問題。

或您可以編寫一套測(cè)試來處理它，並在每次程式碼更改時(shí)運(yùn)行它們。

所以，是的，編寫單元測(cè)試可能會(huì)花費(fèi)大量時(shí)間，但看看每次修改程式碼單元時(shí)節(jié)省的時(shí)間。這是非常值得的，這可以幫助儘早發(fā)現(xiàn)問題（即在發(fā)佈到生產(chǎn)之前），這些問題可能會(huì)因?yàn)橛腥送浤M測(cè)試的一種排列而被錯(cuò)過。

自我記錄

在編寫單元測(cè)試時(shí)，您不僅可以透過確保程式碼實(shí)際運(yùn)作來提高程式碼質(zhì)量，而且本質(zhì)上還可以提供面向開發(fā)人員的文件。

如果您正在對(duì)產(chǎn)品中建置的功能進(jìn)行單元測(cè)試，您將提供有關(guān)功能如何運(yùn)作、何時(shí)應(yīng)該失敗以及何時(shí)應(yīng)該通過的文件。

隨之而來的是一些假設(shè)：具體來說，您正在邏輯地命名和分組您的函數(shù)及其相關(guān)測(cè)試，並且您正在正確測(cè)試每個(gè)函數(shù)。

透過 PHPUnit，WordPress 單元測(cè)驗(yàn)可以輕鬆執(zhí)行易於閱讀的斷言。您只需聲明assertTrue、assertFalse 或組成專案的函數(shù)上可用的任何其他斷言。

按照上面的範(fàn)例，這表示您可以編寫一個(gè)函數(shù)來確保使用者註冊(cè)函數(shù)在嘗試使用空電子郵件地址註冊(cè)時(shí)失?。?/p>

$this->assertFalse( registerNewUser( '' ) );

也許是一個(gè)簡(jiǎn)單的例子，但重點(diǎn)仍然是：您的程式碼變得自文檔化，並且只需要您編寫清晰的單元測(cè)試。

架構(gòu)

也許單元測(cè)試最被低估的優(yōu)勢(shì)之一是它可以幫助驅(qū)動(dòng)專案的架構(gòu)。通常，主題或外掛程式開發(fā)可以透過以下兩種方式之一開始：

1. 列出函數(shù)，繪製使用者介面，然後編寫程式碼
2. 畫出文件如何協(xié)同工作的圖表，然後寫程式碼

這些本質(zhì)上並不是壞事，但我認(rèn)為它們很弱（我會(huì)是第一個(gè)承認(rèn)我所做的事情比我想分享的要多的人?。５恰妇帉懗淌酱a」步驟需要承擔(dān)很多責(zé)任，不是嗎？

對(duì)於任何一個(gè)長(zhǎng)時(shí)間編寫程式碼的人來說，你都太熟悉了，以至於你最終會(huì)意識(shí)到，“哦......我沒有想到這一點(diǎn)。”

如果你幸運(yùn)的話，這通常意味著你可以編寫一個(gè)輔助方法或另一個(gè)條件來處理你忽略的情況，但在最壞的情況下，這意味著你可能必須重新設(shè)計(jì)你的整個(gè)類別或整個(gè)集合解決這個(gè)問題的函數(shù)。

單元測(cè)試雖然不完美，但可以幫助緩解這種情況。

考慮一下這樣一個(gè)事實(shí)：從一開始，您就列出了您希望主題或外掛程式提供的所有功能。您尚未編寫任何程式碼，但也許您有某種類型的 UI 草圖和/或一組類別圖。

接下來，您開始編寫要編寫的測(cè)試以測(cè)試您的項(xiàng)目?；叵胍幌?，單元測(cè)試的一部分是將代碼分解為盡可能的原子單元，因此您的任務(wù)是為每個(gè)單元編寫單元測(cè)試，咳咳。

由于單元測(cè)試的性質(zhì)，您本質(zhì)上會(huì)以不同的方式思考您的代碼：您正在考慮“編寫測(cè)試”，而不是“編寫代碼”，并且因?yàn)槟仨氃诟拥募?jí)別上進(jìn)行思考，您會(huì)情不自禁地考慮經(jīng)常被歸入“編寫代碼”的邊緣案例。

代碼的語(yǔ)言

作為開發(fā)人員，我們非常習(xí)慣使用不斷強(qiáng)化我們編寫代碼的約定。我的意思是，我們傾向于提供縮寫的變量名稱、神秘的函數(shù)名稱和類名稱，這些名稱對(duì)于您自己或項(xiàng)目團(tuán)隊(duì)之外的任何人來說可能沒有任何意義。

單元測(cè)試不一定是編寫更易于閱讀的代碼的關(guān)鍵，但它可以進(jìn)一步幫助提供更清晰的函數(shù)名稱。

回想一下您讀過的第一本編程書、您參加的第一堂計(jì)算機(jī)科學(xué)課或者您看到的第一段開源代碼，方法名稱通常是動(dòng)詞。為什么他們不應(yīng)該這樣？方法是封裝代碼的方法，做一些事情。但隨著我們?cè)陧?xiàng)目上工作的時(shí)間越來越長(zhǎng)，我們變得越來越懶，我們的代碼從“register_user_and_email_password()”變成“new_account()”。

顯然，前者比后者更清晰，但如果我們致力于高質(zhì)量的單元測(cè)試，并且希望確保我們的單元測(cè)試易于閱讀，為了使它們易于閱讀，我們的函數(shù)名稱必須易于閱讀。

這不是更容易閱讀嗎：

$this->assertFalse( register_user_and_email_password( '' ) );

而不是這個(gè)？

$this->assertFalse( new_account( '' ) );

同樣，這也許是一個(gè)簡(jiǎn)單的示例，但原則仍然是：編寫良好的單元測(cè)試，以幫助自我記錄驅(qū)動(dòng)函數(shù)語(yǔ)言的代碼。

結(jié)論

我們已經(jīng)討論了單元測(cè)試的基礎(chǔ)知識(shí)以及主要優(yōu)點(diǎn)，但是我們還沒有討論單元測(cè)試帶來的缺點(diǎn)，我們甚至還沒有考慮如何將其合并到我們的項(xiàng)目中。工作流程。

因此，在下一篇文章中，我們將嘗試做到這一點(diǎn)。