如何開始使用 Pest PHP 測試框架測試您的 WordPress 代碼

我們都同意 WordPress 從一開始就已經走過了漫長的道路，而且它發展成為的不僅僅是博客軟件。

它的核心仍然是一個內容管理系統 (CMS)，但 wordpress.org 目錄中有超過 59,000 個插件，您可以對其進行自定義以實現更多功能。

它受歡迎的原因是它對內容創建者和開發者的准入門檻低。 有時這需要付出代價。 WordPress 在開發方面名聲不佳，這已不是什麼秘密。 它有很多遺留的包袱和頑固的規則，可以防止在涉及 PHP 代碼時發生任何向後兼容性的破壞性更改（Gutenberg 是另一個我不會討論的故事）。

那些開始進入編程世界的開發人員經常使用遺留的 PHP 代碼，問題是他們可以學習一些糟糕的編程模式。 這反過來意味著他們將重用編寫不佳的代碼，從而增加世界上糟糕代碼的數量。

這就是 WordPress 在開發者社區中名聲不佳的地方。

打破循環

那麼我們如何才能打破這種糟糕代碼的循環呢？ 通過教新開發人員如何編寫好的代碼。 教新開發人員（以及仍然堅持“WordPress”做事方式的老開發人員）的一個例子是編寫教程。

另一種方法是鼓勵他們使用可以幫助他們編寫更好代碼的工具。

我目前正在參與旨在發布新版 WordPress 編碼標準的工作，這是一組用於 PHP_CodeSniffer 工具的規則，可以讓您知道您的代碼是否存在一些潛在問題（安全性、最佳實踐、代碼風格）。

我最近開發的另一個工具是一個包，它可以幫助開發人員設置使用 Pest 測試框架的 WordPress 集成測試。

好的，那麼為什麼我們需要這個新工具呢？

創建這個包的主要動機是鼓勵更多的人為他們的代碼編寫測試，尤其是插件開發人員。

WordPress 社區中的許多開發人員都遵循這樣的口頭禪：我可以看到它有效，因為我已經在我的瀏覽器中嘗試過了。 沒關係，但是這樣做有問題。

首先，它很耗時。 每次你做出一些改變，你都需要確保它有效，而且你沒有破壞任何東西。

其次，人會犯錯。 我們並非萬無一失，代碼可能會以您從未想過的方式被濫用。 您會驚訝於人們在編寫代碼時的創造力。

自動化測試速度很快，可以幫助您測試執行代碼時會發生的各種情況。

您測試預期的行為（快樂路徑），並且可以快速添加示例，說明如何以您不希望使用的方式使用代碼（不快樂路徑）。

它還可以保護您的代碼免受回歸。 代碼回歸是指您通過添加新代碼無意中破壞了代碼的一部分。

到目前為止設置的測試問題

在 WordPress 中進行測試並不是什麼新鮮事。 並不是說您以前無法為您的代碼設置測試。 有很多很棒的庫可以幫助你設置一切，比如 wp-browser。

但問題是設置過程通常很笨拙。

您需要為測試設置一個單獨的數據庫，並且您需要運行某些腳本，然後更改文件以使其全部工作。

讓我們面對現實吧，這不是一件簡單的事情，開發人員天生就是懶惰的生物（這就是我們編寫代碼為我們做事的原因）。

wp-pest 集成測試設置的目的是消除所有額外的工作。

如何設置

為了設置它，您的項目必須使用 Composer。 這是將包添加到代碼中的事實上的標準方式。

在您的終端類型中

composer require dingo-d/wp-pest-integration-test-setup --dev

下載包及其依賴項後，您可以通過鍵入來設置主題測試

vendor/bin/wp-pest setup theme

或者，如果您想為插件設置測試，您可以編寫

vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slug

或者，您可以提供--wp-version參數，以指定您想在哪個 WordPress 版本上測試您的代碼。

在後台，將下載一個 WordPress 實例，並設置一個內存數據庫，以及您可以運行的兩個測試示例。

然後，運行

vendor/bin/pest --group=unit

或者

vendor/bin/pest --group=integration

將運行測試。

Pest 的美妙之處在於它的語法對開發人員友好。 它具有驚人的文檔和出色的語法。 讓我們看一個簡單的例子。 假設您正在註冊一個名為“書籍”的自定義帖子類型：

 <?php /** * Plugin Name: Test plugin * Desctiption: Test plugin * Version: 1.0.0 * License: MIT */ function test_plugin_register_books_cpt() { $args = array( 'label' => 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', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ), ); register_post_type( 'book', $args ); } add_action( 'init', 'test_plugin_register_books_cpt' );

運行添加示例的 setup 命令後，名為BooksCptTest.php的測試將如下所示：

 <?php namespace Tests\Integration; beforeEach(function () { parent::setUp(); }); afterEach(function () { parent::tearDown(); }); test('Books custom post type is registered', function () { // We can use assertions from PHP_Unit. $this->assertNotFalse(has_action('init', 'test_plugin_register_books_cpt')); $registeredPostTypes = \get_post_types(); // Or we can use expectations API from Pest. expect($registeredPostTypes) ->toBeArray() ->toHaveKey('book'); });

運行vendor/bin/pest --group=integration給我們以下輸出：

 Installing... Running as single site... To run multisite, use -c tests/phpunit/multisite.xml Not running ajax tests. To execute these, use --group ajax. Not running ms-files tests. To execute these, use --group ms-files. Not running external-http tests. To execute these, use --group external-http. PASS Tests\\Integration\\BooksCptTest ✓ Books custom post type is registered Tests: 1 passed Time: 0.14s

結論

就像這樣，您可以在您的主題或插件中運行 WordPress 集成測試。 測試之所以令人驚奇，是因為它們不僅可以保護我們免於錯誤，還可以迫使我們編寫乾淨且可測試的代碼。 對於邏輯複雜或與第三方 API 通信的插件尤其如此。

為這樣的代碼庫編寫測試將迫使您考慮您的代碼架構是什麼樣的，以便您可以輕鬆編寫自動化測試 - 更不用說您不必手動測試所有內容所節省的時間和金錢。

如果您認為這是您可能會從中受益的東西，請隨意使用它，並在 GitHub 上為存儲庫加註星標。

希望這將鼓勵更多的 WordPress 開發人員使用能夠提高他們編碼技能的工具。