我們都同意 WordPress 從一開始就已經走過了漫長的道路，而且它發展成為的不僅僅是博客軟體。
它的核心仍然是一個內容管理系統 (CMS)，但它擁有超過 59,000 個插件 wordpress.org 目錄，您可以自定義更多。
它受歡迎的原因是它對內容創建者和開發者的准入門檻低。 有時這需要付出代價。 WordPress 在開發方面名聲不佳，這已不是什麼秘密。 它有很多遺留的包袱和頑固的規則，可以防止在涉及 PHP 代碼時發生任何向後兼容性的破壞性更改（Gutenberg 是另一個我不會討論的故事）。
那些開始進入編程世界的開發人員經常使用遺留的 PHP 代碼，問題是他們可以學習一些糟糕的編程模式。 這反過來意味著他們將重用編寫不佳的代碼，從而增加世界上糟糕代碼的數量。
這就是 WordPress 在開發者社區中名聲不佳的地方。
打破循環
那麼我們如何才能打破這種糟糕代碼的循環呢？ 通過教新開發人員如何編寫好的代碼。 教新開發人員（以及仍然堅持「WordPress」做事方式的老開發人員）的一個例子是編寫教程。
另一種方法是鼓勵他們使用可以幫助他們編寫更好代碼的工具。
我目前正在參與旨在發布新版本的工作 WordPress 編碼標準，一組規則用於 PHP_CodeSniffer 如果您的代碼存在一些潛在問題（安全性、最佳實踐、代碼風格），該工具會讓您知道。
我最近開發的另一個工具是 包裹 這將幫助開發人員設置使用 害蟲 測試框架。
好的，那麼為什麼我們需要這個新工具呢？
創建這個包的主要動機是鼓勵更多的人為他們的代碼編寫測試，尤其是插件開發人員。
WordPress 社區中的許多開發人員都遵循這樣的口頭禪：我可以看到它有效，因為我已經在我的瀏覽器中嘗試過了。 沒關係，但是這樣做有問題。
首先，它很耗時。 每次你做出一些改變，你都需要確保它有效，而且你沒有破壞任何東西。
其次，人會犯錯。 我們並非萬無一失，代碼可能會以您從未想過的方式被濫用。 您會驚訝於人們在編寫代碼時的創造力。
自動化測試速度很快，可以幫助您測試執行代碼時會發生的各種情況。
您測試預期的行為（快樂路徑），並且可以快速添加示例，說明如何以您不希望使用的方式使用您的代碼（不快樂路徑）。
它還可以保護您的代碼免受回歸。 代碼回歸是指您通過添加新代碼無意中破壞了代碼的一部分。
到目前為止設置的測試問題
在 WordPress 中進行測試並不是什麼新鮮事。 並不是說您以前無法為您的代碼設置測試。 那裡有很棒的庫可以幫助您設置所有內容，例如 wp瀏覽器.
但問題是設置過程通常很笨拙。
您需要為測試設置一個單獨的資料庫，並且您需要運行某些腳本，然後更改文件以使其全部工作。
面對現實吧，這不是一件簡單的事情，開發人員天生就是懶惰的生物（這就是我們編寫代碼為我們做事的原因😄）。
wp-pest 集成測試設置的目的是消除所有額外的工作。
如何設置
為了設置它，您的項目必須使用 作曲家. 這是將包添加到代碼中的事實上的標準方式。
在您的終端類型中
作曲家需要 dingo-d/wp-pest-integration-test-setup –dev
下載包及其依賴項後，您可以通過鍵入來設置主題測試
vendor/bin/wp-pest 設置主題
或者，如果您想為插件設置測試，您可以編寫
供應商/bin/wp-pest 設置插件 –plugin-slug=your-plugin-slug
或者，您可以提供 –wp-version 參數，以指定您想在哪個 WordPress 版本上測試您的代碼。
在後台，將下載一個 WordPress 實例，並設置一個內存資料庫，以及您可以運行的兩個測試示例。
然後，運行
供應商/bin/害蟲 –group=unit
或者
供應商/bin/害蟲–group=integration
將運行測試。
Pest 的美妙之處在於它的語法對開發人員友好。 它有 驚人的文檔 和偉大的語法。 讓我們看一個簡單的例子。 假設您正在註冊一個名為「書籍」的自定義帖子類型：
esc_html__( ‘Books’, ‘test-plugin’ ), ‘public’ => true, ‘publicly_queryable’ => true, ‘show_ui’ => true, ‘show_in_menu’ => true, ‘query_var’ => true, ‘rewrite’ => array(‘ slug’ => ‘book’ ), ‘capability_type’ => ‘post’, ‘has_archive’ => true, ‘hierarchical’ => false, ‘menu_position’ => null, ‘supports’ => array(‘title’, ‘編輯’，’作者’，’縮略圖’，’摘錄’，’評論’），）； register_post_type(‘書’，$args); } add_action(‘init’, ‘test_plugin_register_books_cpt’);
運行添加示例的 setup 命令後，名為 BooksCptTest.php 的測試將如下所示：
assertNotFalse(has_action(‘init’, ‘test_plugin_register_books_cpt’)); $registeredPostTypes = \get_post_types(); // 或者我們可以使用 Pest 的期望 API。expect($registeredPostTypes) ->toBeArray() ->toHaveKey(‘book’); });
運行 vendor/bin/pest –group=integration 給我們以下輸出：
安裝…作為單個站點運行…要運行多站點，請使用 -c tests/phpunit/multisite.xml 不運行 ajax 測試。 要執行這些，請使用 –group ajax。 不運行 ms-files 測試。 要執行這些，請使用 –group ms-files。 不運行 external-http 測試。 要執行這些，請使用 –group external-http。 PASS Tests\\Integration\\BooksCptTest ✓ Books 自定義帖子類型已註冊測試：1 通過時間：0.14s
結論
就像這樣，您可以在您的主題或插件中運行 WordPress 集成測試。 測試之所以令人驚奇，是因為它們不僅可以保護我們免於錯誤，還可以迫使我們編寫乾淨且可測試的代碼。 對於邏輯複雜或與第三方 API 通信的插件尤其如此。
為這樣的代碼庫編寫測試將迫使您考慮您的代碼架構是什麼樣的，以便您可以輕鬆編寫自動化測試 – 更不用說您不必手動測試所有內容所節省的時間和金錢。
如果您認為這是您可能會從中受益的東西，請隨意使用它，並且 為存儲庫加註星標 在 GitHub 上。
希望這將鼓勵更多的 WordPress 開發人員使用能夠提高他們編碼技能的工具。