Pest PHP Test Çerçevesi ile WordPress Kodunuzu Test Etmeye Nasıl Başlanır

WordPress'in başlangıcından bu yana çok yol kat ettiği ve blog yazılımından çok daha fazla bir şeye dönüştüğü konusunda hepimiz hemfikiriz.

Özünde, hala bir içerik yönetim sistemidir (CMS), ancak wordpress.org dizininde 59.000'den fazla eklenti ile onu çok daha fazlası olacak şekilde özelleştirebilirsiniz.

Popülerliğinin nedeni, hem içerik oluşturucular hem de geliştiriciler için düşük giriş engelidir. Bazen bunun bir bedeli vardır. Konu geliştirme olduğunda WordPress'in kötü bir üne sahip olduğu bir sır değil. PHP kodu söz konusu olduğunda herhangi bir geriye dönük uyumluluk değişikliğini engelleyen çok sayıda eski bagaj ve zorlu kurallara sahiptir (Gutenberg, girmeyeceğim başka bir hikaye).

Bu eski PHP kodu, genellikle programlama dünyasına girmeye başlayan geliştiriciler tarafından kullanılır ve bununla ilgili sorun, bazı kötü programlama kalıplarını öğrenebilmeleridir. Bu da, kötü yazılmış kodu yeniden kullanacakları ve dünyadaki kötü kod miktarını artıracakları anlamına gelir.

WordPress'in geliştirici topluluğundaki kötü itibarını aldığı yer burasıdır.

döngüyü kırmak

Peki bu kötü kod döngüsünü nasıl kırabiliriz? Yeni geliştiricilere nasıl iyi kod yazmaları gerektiğini öğreterek. Yeni geliştiricilere (aynı zamanda hala 'WordPress' bir şeyler yapma yöntemine bağlı kalan eski geliştiricilere) öğretmenin bir örneği, öğreticiler yazmaktır.

Başka bir yol da onları daha iyi kod yazmalarına yardımcı olabilecek araçları kullanmaya teşvik etmektir.

Şu anda, PHP_CodeSniffer aracı için kullanılan ve kodunuzda bazı olası sorunlar (güvenlik, en iyi uygulamalar, kod stili) olup olmadığını size bildirecek bir dizi kural olan WordPress Kodlama Standartlarının yeni sürümünü yayınlamayı amaçlayan çalışmayla ilgileniyorum. ).

Yakın zamanda geliştirdiğim başka bir araç, geliştiricilerin Pest test çerçevesini kullanan WordPress entegrasyon testleri oluşturmasına yardımcı olacak bir paket.

Tamam, öyleyse neden bu yeni araca ihtiyacımız var?

Bu paketi oluşturmanın arkasındaki ana motivasyon, daha fazla insanı, özellikle eklenti geliştiricileri olmak üzere kodları için testler yazmaya teşvik etmektir.

WordPress topluluğundaki birçok geliştirici şu mantrayı benimsiyor: Tarayıcımda denediğim için işe yaradığını görebiliyorum. Sorun değil ama bununla ilgili sorunlar var.

İlk olarak, zaman alıcıdır. Her değişiklik yaptığınızda, çalıştığından emin olmanız gerekir, aynı zamanda hiçbir şeyi bozmadığınızdan da.

İkincisi, insanlar hata yapar. Kusursuz değiliz ve kod, asla mümkün olmadığını düşündüğünüz şekillerde kötüye kullanılabilir. İnsanların kod yazarken ne kadar yaratıcı olabileceğine şaşıracaksınız.

Otomatik testler hızlıdır ve kodunuzu çalıştırdığınızda meydana gelecek çeşitli durumları test etmenize yardımcı olabilir.

Amaçlanan davranışı (mutlu yol) test edersiniz ve hızlı bir şekilde, kodunuzun kullanılmasını istemediğiniz bir şekilde (mutsuz yol) nasıl kullanılabileceğine dair örnekler ekleyebilirsiniz.

Ayrıca kodunuzu gerilemelerden korur. Kod gerilemesi, istemeden yeni kod ekleyerek kodunuzun bir bölümünü kırmanızdır.

Şimdiye kadar kurulan testlerle ilgili sorun

WordPress'te test etmek yeni bir şey değil. Ve daha önce kodunuz için testler ayarlayamadığınız gibi değil. Her şeyi wp-tarayıcı gibi ayarlamanıza yardımcı olacak harika kütüphaneler var.

Ancak sorun şu ki, kurulum prosedürü genellikle karmaşıktır.

Testler için ayrı bir veritabanı kurmanız ve belirli komut dosyalarını çalıştırmanız ve ardından her şeyin çalışması için dosyaları değiştirmeniz gerekir.

Kabul edelim, bu yapılacak basit bir şey değil ve geliştiriciler doğası gereği tembel yaratıklardır (bu yüzden bizim için bir şeyler yapmak için kod yazıyoruz).

wp-pest entegrasyon test kurulumunun amacı tüm bu ekstra işleri ortadan kaldırmaktır.

nasıl kurulur

Bunu kurmak için projenizin Composer kullanması gerekir. Bu, kodunuza paket eklemenin fiili standart bir yoludur.

Terminal tipinizde

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

Paketi ve bağımlılıklarını indirdikten sonra yazarak tema testlerini ayarlayabilirsiniz.

 vendor/bin/wp-pest setup theme

Veya eklentiniz için testler kurmak istiyorsanız yazabilirsiniz.

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

İsteğe bağlı olarak, kodunuzu hangi WordPress sürümünde test etmek istediğinizi belirtmek için bir --wp-version parametresi sağlayabilirsiniz.

Arka planda, bir WordPress örneği indirilecek ve çalıştırabileceğiniz iki test örneğiyle birlikte bir bellek içi veritabanı kurulacaktır.

Ardından, ya koşmak

 vendor/bin/pest --group=unit

veya

 vendor/bin/pest --group=integration

testleri yapacak.

Pest'in güzelliği, sözdiziminin geliştirici dostu olmasıdır. Harika belgelere ve harika sözdizimine sahiptir. Basit bir örneğe bakalım. 'Kitaplar' adında özel bir gönderi türü kaydettirdiğinizi varsayalım:

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

Örnek ekleyen setup komutunu çalıştırdıktan sonra, BooksCptTest.php adlı bir test şöyle görünür:

 <?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 çalıştırmak bize aşağıdaki çıktıyı verir:

 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

Çözüm

Ve bunun gibi, temanızda veya eklentinizde WordPress entegrasyon testleri yapma olanağına sahipsiniz. Testler harikadır çünkü bizi yalnızca hatalardan korumakla kalmaz, aynı zamanda temiz ve test edilebilir kodlar yazmaya da zorlarlar. Bu, özellikle karmaşık mantığı olan veya üçüncü taraf API'lerle iletişim kuran eklentiler için geçerlidir.

Böyle bir kod tabanı için testler yazmak, sizi kod mimarinizin neye benzediğini düşünmeye zorlar, böylece kolayca otomatik testler yazabilirsiniz - her şeyi manuel olarak test etmek zorunda kalmadan tasarruf edeceğiniz zamandan ve paradan bahsetmiyorum bile.

Bunun faydalanabileceğiniz bir şey olduğunu düşünüyorsanız, kullanmaktan çekinmeyin ve GitHub'daki depoya yıldız ekleyin.

Umarım bu, daha fazla WordPress geliştiricisini kodlama becerilerini geliştirecek araçları kullanmaya teşvik edecektir.