單元測試理論（續）：第 2 部分

#在上一篇文章中，我們開始討論 WordPress 中的單元測試理論。具體來說，我們回顧了我們在單元測試主題和插件方面的工作，然後開始討論程式碼單元，這如何影響我們的測試，並且我們回顧了更大的軟體開發世界中的單元測試。

我們將繼續討論 WordPress 中的單元測試理論，但會從它如何幫助識別問題、驅動架構、記錄專案等角度進行討論。

---

發現問題，節省時間

回想一下本系列前面的內容，進行單元測試的傳統方法是這樣的：

• 寫測試，運行它（知道它會失敗）
• 編寫函數以使該方法通過。
• 運行測試。如果測試失敗，則繼續處理該功能；否則，請轉到下一個。

是的，第一步有點教條。為什麼要浪費時間去運行一些你知道會失敗的東西，對吧？不過，你明白了。但是當您開始將這種特殊技術應用於開發時，您會發現編寫程式碼時會形成一定的節奏，而這是整個目標的一部分。

但這只是其中的一半——單元測試實際上可以幫助您在開發早期發現問題。

為了理解這一點，最好回顧一下這個想法。

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

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

或您可以編寫一套測試來處理它，並在每次程式碼更改時運行它們。

所以，是的，編寫單元測試可能會花費大量時間，但看看每次修改程式碼單元時節省的時間。這是非常值得的，這可以幫助儘早發現問題（即在發佈到生產之前），這些問題可能會因為有人忘記模擬測試的一種排列而被錯過。

---

自我記錄

在編寫單元測試時，您不僅可以透過確保程式碼實際運作來提高程式碼質量，而且本質上還可以提供面向開發人員的文件。

如果您正在對產品中建置的功能進行單元測試，您將提供有關功能如何運作、何時應該失敗以及何時應該通過的文件。

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

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

按照上面的範例，這表示您可以編寫一個函數來確保使用者註冊函數在嘗試使用空電子郵件地址註冊時失敗：

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

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

---

架構

也許單元測試最被低估的優勢之一是它可以幫助驅動專案的架構。通常，主題或外掛程式開發可以透過以下兩種方式之一開始：

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

這些本質上並不是壞事，但我認為它們很弱（我會是第一個承認我所做的事情比我想分享的要多的人！）。但是「編寫程式碼」步驟需要承擔很多責任，不是嗎？

對於任何一個長時間編寫程式碼的人來說，你都太熟悉了，以至於你最終會意識到，“哦......我沒有想到這一點。”

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

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

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

接下来，您开始编写要编写的测试以测试您的项目。回想一下，单元测试的一部分是将代码分解为尽可能的原子单元，因此您的任务是为每个单元编写单元测试，咳咳。

由于单元测试的性质，您本质上会以不同的方式思考您的代码：您正在考虑“编写测试”，而不是“编写代码”，并且因为您必须在更原子的级别上进行思考，您会情不自禁地考虑经常被归入“编写代码”的边缘案例。

---

代码的语言

作为开发人员，我们非常习惯使用不断强化我们编写代码的约定。我的意思是，我们倾向于提供缩写的变量名称、神秘的函数名称和类名称，这些名称对于您自己或项目团队之外的任何人来说可能没有任何意义。

单元测试不一定是编写更易于阅读的代码的关键，但它可以进一步帮助提供更清晰的函数名称。

回想一下您读过的第一本编程书、您参加的第一堂计算机科学课或者您看到的第一段开源代码，方法名称通常是动词。为什么他们不应该这样？方法是封装代码的方法，做一些事情。但随着我们在项目上工作的时间越来越长，我们变得越来越懒，我们的代码从“register_user_and_email_password()”变成“new_account()”。

显然，前者比后者更清晰，但如果我们致力于高质量的单元测试，并且希望确保我们的单元测试易于阅读，为了使它们易于阅读，我们的函数名称必须易于阅读。

这不是更容易阅读吗：

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

而不是这个？

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

同样，这也许是一个简单的示例，但原则仍然是：编写良好的单元测试，以帮助自我记录驱动函数语言的代码。

---

结论

我们已经讨论了单元测试的基础知识以及主要优点，但是我们还没有讨论单元测试带来的缺点，我们甚至还没有考虑如何将其合并到我们的项目中。工作流程。

因此，在下一篇文章中，我们将尝试做到这一点。

以上是單元測試理論（續）：第 2 部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！