Cara Mulai Menguji Kode WordPress Anda Dengan Kerangka Pengujian PHP Pest

Kita semua bisa setuju bahwa WordPress telah berkembang jauh sejak awal dan tumbuh menjadi sesuatu yang lebih dari sekadar perangkat lunak blogging.

Pada intinya, ini masih merupakan sistem manajemen konten (CMS), tetapi dengan lebih dari 59.000 plugin di direktori wordpress.org, Anda dapat menyesuaikannya menjadi lebih banyak lagi.

Alasan popularitasnya adalah penghalang masuk yang rendah untuk pembuat konten dan pengembang. Terkadang ini datang dengan biaya. Bukan rahasia lagi bahwa WordPress memiliki reputasi buruk dalam hal pengembangan. Ini memiliki banyak bagasi warisan dan aturan keras yang mencegah perubahan kompatibilitas mundur ketika datang ke kode PHP (Gutenberg adalah cerita lain yang tidak akan saya bahas).

Kode PHP lawas itu sering digunakan oleh para pengembang yang mulai memasuki dunia pemrograman, dan masalahnya adalah mereka dapat mempelajari beberapa pola pemrograman yang buruk. Itu pada gilirannya berarti mereka akan menggunakan kembali kode yang ditulis dengan buruk, meningkatkan jumlah kode buruk di dunia.

Di sinilah WordPress mendapatkan reputasi buruknya di komunitas pengembang.

Memutus siklus

Jadi bagaimana kita bisa memutus siklus kode buruk ini? Dengan mengajari pengembang baru bagaimana mereka harus menulis kode yang baik. Salah satu contoh mengajar pengembang baru (tetapi juga pengembang lama yang masih berpegang teguh pada cara 'WordPress' dalam melakukan sesuatu) adalah dengan menulis tutorial.

Cara lain adalah dengan mendorong mereka untuk menggunakan alat yang dapat membantu mereka menulis kode yang lebih baik.

Saat ini saya terlibat dalam pekerjaan yang bertujuan untuk merilis versi baru Standar Pengkodean WordPress, seperangkat aturan yang digunakan untuk alat PHP_CodeSniffer yang akan memberi tahu Anda jika kode Anda memiliki beberapa masalah potensial (keamanan, praktik terbaik, gaya kode ).

Alat lain yang baru-baru ini saya kembangkan adalah paket yang akan membantu pengembang menyiapkan tes integrasi WordPress yang menggunakan kerangka pengujian Pest.

Oke, jadi mengapa kita membutuhkan alat baru ini?

Motivasi utama di balik pembuatan paket ini adalah untuk mendorong lebih banyak orang menulis tes untuk kode mereka, terutama pengembang plugin.

Banyak pengembang di komunitas WordPress menggunakan mantra: Saya dapat melihat bahwa itu berhasil karena saya telah mencobanya di browser saya. Tidak apa-apa, tapi ada masalah dengan itu.

Pertama, itu memakan waktu. Setiap kali Anda membuat beberapa perubahan, Anda perlu memastikan itu berfungsi, tetapi juga tidak merusak apa pun.

Kedua, orang membuat kesalahan. Kami tidak sangat mudah, dan kode dapat disalahgunakan dengan cara yang Anda tidak pernah berpikir mungkin. Anda akan takjub melihat betapa kreatifnya orang saat menulis kode.

Pengujian otomatis berlangsung cepat dan dapat membantu Anda menguji berbagai kasus yang akan terjadi saat Anda menjalankan kode.

Anda menguji perilaku yang diinginkan (jalur bahagia), dan dengan cepat, Anda dapat menambahkan contoh bagaimana kode Anda dapat digunakan dengan cara yang tidak Anda inginkan (jalur tidak bahagia).

Itu juga melindungi kode Anda dari regresi. Regresi kode adalah ketika Anda secara tidak sengaja merusak satu bagian dari kode Anda dengan menambahkan kode baru.

Masalah dengan tes yang disiapkan sejauh ini

Pengujian di WordPress bukanlah hal baru. Dan itu tidak seperti Anda tidak dapat mengatur tes untuk kode Anda sebelumnya. Ada perpustakaan luar biasa di luar sana yang akan membantu Anda mengatur semuanya seperti wp-browser.

Tetapi masalahnya adalah prosedur pengaturannya sering kali kikuk.

Anda perlu menyiapkan database terpisah untuk pengujian, dan Anda perlu menjalankan skrip tertentu, lalu mengubah file agar semuanya berfungsi.

Mari kita hadapi itu, itu bukan hal yang mudah untuk dilakukan, dan pengembang pada dasarnya adalah makhluk yang malas (itulah sebabnya kami menulis kode untuk melakukan sesuatu untuk kami).

Tujuan dari pengaturan pengujian integrasi wp-pest adalah untuk menghilangkan semua pekerjaan ekstra itu.

Bagaimana cara mengaturnya?

Untuk mengaturnya, proyek Anda harus menggunakan Komposer. Ini adalah cara standar de-facto untuk menambahkan paket ke kode Anda.

Di terminal Anda ketik

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

Setelah Anda mengunduh paket dan dependensinya, Anda dapat mengatur tes tema dengan mengetik

 vendor/bin/wp-pest setup theme

Atau, jika Anda ingin menyiapkan pengujian untuk plugin Anda, Anda dapat menulis

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

Secara opsional, Anda dapat memberikan parameter --wp-version , untuk menentukan versi WordPress mana yang ingin Anda uji kodenya.

Di latar belakang, instance WordPress akan diunduh, dan database dalam memori akan disiapkan, bersama dengan dua contoh pengujian yang dapat Anda jalankan.

Lalu, lari juga

 vendor/bin/pest --group=unit

atau

 vendor/bin/pest --group=integration

akan menjalankan tes.

Keindahan Pest adalah sintaksnya ramah pengembang. Ini memiliki dokumentasi yang luar biasa dan sintaks yang bagus. Mari kita lihat contoh sederhana. Katakanlah Anda mendaftarkan jenis posting khusus yang disebut 'Buku':

 <?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' );

Setelah menjalankan perintah setup yang menambahkan contoh, tes yang disebut BooksCptTest.php akan terlihat seperti ini:

 <?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'); });

Menjalankan vendor/bin/pest --group=integration memberi kita output berikut:

 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

Kesimpulan

Dan begitu saja, Anda memiliki kemampuan untuk menjalankan tes integrasi WordPress di tema atau plugin Anda. Pengujian luar biasa karena tidak hanya melindungi kita dari kesalahan, tetapi juga memaksa kita untuk menulis kode yang bersih dan dapat diuji. Ini terutama berlaku untuk plugin yang memiliki logika rumit atau berkomunikasi dengan API pihak ketiga.

Menulis tes untuk basis kode semacam itu akan memaksa Anda untuk memikirkan seperti apa arsitektur kode Anda sehingga Anda dapat dengan mudah menulis tes otomatis – belum lagi waktu dan uang yang Anda hemat karena tidak harus menguji semuanya secara manual.

Jika menurut Anda ini adalah sesuatu yang dapat Anda manfaatkan, jangan ragu untuk menggunakannya, dan beri bintang pada repositori di GitHub.

Mudah-mudahan, ini akan mendorong lebih banyak pengembang WordPress untuk menggunakan alat yang akan meningkatkan keterampilan pengkodean mereka.