WordPress için Birim Testine Giriş

PHP uygulamalarının birim testi hakkında pek çok içerik bulabilmenize rağmen, özellikle WordPress için birim testi hakkında konuşan pek fazla kişi yok. Kod kalitesini artırmaya hazır olan ve çalışmalarına nasıl test ekleyeceklerini öğrenmek isteyen geliştiriciler için nereden başlayacakları konusunda çok az şey yazılmış. Daha da kötüsü, WordPress'teki birim testi araçlarının bazıları reklamı yapıldığı gibi çalışmıyor veya PHPUnit'in eski sürümlerini kullanıyor. Teste başlamaya çalışırken kendi başınıza keşfetmeniz gereken sorunlar.

Bu, eklentileri için temel varsayılan testleri bile çalıştırmak için birkaç saatlik bir yolculukta teste başlamak isteyen birçok insanı bırakıyor.

Bugün size WordPress kodunuzu birim testine nasıl başlatacağınıza dair güncel bir bakış sunarak bu sorunu çözeceğiz.

Kurulması Gerekenler

Birim testine dalmadan önce, sahip olduğunuzu varsayacağım. Laravel Vale Ve WP CLI Kurulmuş. Vale'yi kurmak için WP Beaches'in bu mükemmel talimatlarını kullanıyorumancak MariaDB talimatlarını değil mysql talimatlarını kullanıyorum.

Kurulum talimatlarını bulabilirsiniz WP CLI WP CLI sitesinde.

Windows kullanıyorsanız, birim testleri çalıştırabilmek için biraz fazladan araştırma yapmanız gerekebilir. WordPress El Kitabı atmanız gereken ekstra adımlara ilişkin bazı talimatlar bulunur.

PHPUnit for WordPress'i Laravel Valet'e yükleyin

İlk adımımız kurulumdur PHPBirimi. PHPUnit şu anda 9.x şubesinde olmasına rağmen, WordPress yalnızca 7.5.x'i desteklemektedir, bu da bu eski sürümü yüklememiz gerektiği anlamına gelir.

Terminali açın ve bu komutları kullanın.

wget https://phar.phpunit.de/phpunit-7.5.9.phar

chmod +x phpunit-7.5.9.phar`

sudo mv phpunit-7.5.9.phar /usr/local/bin/phpunit

phpunit –versiyon

Yukarıdaki komut PHPUnit'i indirin. Daha sonra dosyayı çalıştırılabilir hale getirerek çalıştırılabilir hale getiriyoruz. Daha sonra dosyayı bilgisayarımızda uygun konuma taşımak için sudo komutunu kullanıyoruz. Son olarak, son komutu çalıştırdığımızda 7.5.9 döndürmesi gereken sürüm numarasını kontrol ediyoruz.

Artık eklentimizi WP CLI ile kurmaya ve ilk testlerimize göz atmaya hazırız.

Eklentimizi Kurmak

Bir eklentiyi başlatmayı ve birim test iskelemizi almayı kolaylaştırabiliriz. WP CLI iskele komutu. Bu komut bizim için bir eklenti oluşturacak ve testlerimiz için temel oluşturmamız gereken tüm dosyaları ekleyecektir.

Terminalde, kullanmak istediğiniz doğru WordPress dizininde olduğunuzdan emin olun ve ardından wp scaffold nexcess-unit-tests yazın. Bu size buna benzeyen bir klasör yapısı sağlamalıdır.

– çöp Kutusu

– install-wp-tests.sh

– testler

– bootstrap.php

– test-örneği.php

– .distignore

– .editorconfig

– .phpcs.xml.dist

– .travis.yml

– Gruntfile.js

– sonraki-birim-testleri.php

– paket.json

– phpunit.xml.dist

– benioku.txt

Kod düzenleyicinizin ve dosya sisteminizin nasıl ayarlandığına bağlı olarak, ile başlayan dosyaları göremeyebilirsiniz. çünkü bunlar gizli dosyalar olarak kabul edilir. Bugünkü amaçlarımız açısından bunların bir önemi yok, dolayısıyla onları göremiyorsanız endişelenmeyin.

Şimdi birim testlerimizi MySQL'e bağlamamız gerekiyor, böylece test edebileceğimiz sahte veriler oluşturabiliyor. WordPress kurulumunuz için wp-config.php dosyasını şimdi açın çünkü bir sonraki komut için db_user ve db_pass'ı bulmanız gerekecek.

Testleri yüklemeyi tamamlamak için eklenti dizininize geçin ve aşağıdaki komutu çalıştırın.

bin/install-wp-tests.sh localhost en son

WordPress kurulumunuzdan farklı bir veritabanı adı kullandığınızdan emin olun. Birim testlerinizin verilerinizle uğraşmasını istemezsiniz, kendi veri tabanında kendi test verilerini oluşturmasını istersiniz. Aksi takdirde, db-user ve db-pass, wp-config.php dosyanızla aynı olacaktır.

Son iki parametre, test çerçevesine localhost'a bağlanmasını ve test edilecek WordPress'in en son sürümünü yüklemesini söyler. Daha iyisini bilmiyorsanız, bu ayarları olduğu gibi bırakın.

Eğer phpunit'i şimdi çalıştırsaydık hala çözmemiz gereken birkaç hata olurdu. İlk olarak, bazı nedenlerden dolayı WP CLI, örnek testlerde name niteliğini bloğa eklemiyor. Phpunit.xml.dist'i açın ve dosyayı değiştirip kaydedin.

Ayrıca burada PHPUnit bloğunun içinde testler/test-sample.php dosyasını yoksaymasının söylendiğini unutmayın. Bu dosyayı kopyalayalım ve test-nexcess.php olarak yeniden adlandıralım, böylece çalışacak bir dosyamız olur. Daha sonra yeni dosyayı açın ve sınıf adını Bana HostingTest olarak değiştirin. Dosya şimdi bu şekilde görünmelidir.

/**

* Sınıf Bana HostingTest

*

* @package Bana Hosting_Unit_Tests

*/

/**

* Örnek test durumu.

*/

Bana HostingTest sınıfı WP_UnitTestCase'i genişletiyor

/**

* Tek örnek test.

*/

genel işlev test_örnek()

// Bunu gerçek bir test koduyla değiştirin.

$this->assertTrue( true );

Artık terminalden phpunit'i çalıştırmaya hazırız. Bunu yaptıktan sonra aşağıdaki resme benzer bir şey görmelisiniz.

Artık PHPUnit'in testlerimizi çalıştırdığını doğruladığımıza göre, biraz daha derine inelim ve WordPress'in kullanıcıları düzgün şekilde eklediğinden emin olmak için bir test yazalım.

kurulum ve sökme

Çoğu birim testi, test veritabanına belirli verilerin eklenmesini gerektirir. Daha sonra testlerinizi bu sahte verilerle çalıştırırsınız. Bunu yapmak için test sınıfınızdaki setUp ve tearDown işlevlerini kullanırsınız.

Bir kullanıcı oluşturalım ve kullanıcının edit_posts yeteneğine sahip olduğundan emin olalım. Aşağıdaki fonksiyonu sınıfınızın en üstüne ekleyin.

genel işlev kurulumu()

// sahte kullanıcı oluştur

$this->author = new WP_User( $this->factory->user->create( array( 'role' => 'editör' ) ) );

Daha sonra bu gözyaşı fonksiyonunu sınıfın sonuna ekleyin.

genel işlev gözyaşıDown()

ebeveyn::tearDown();

wp_delete_user($this->yazar->ID, true);

Bu, testlerimizi çalıştırmadan önce editör rolüne sahip bir kullanıcı ekler ve testlerimizi çalıştırdıktan sonra kullanıcıyı kaldırır.

Şimdi kullanıcının düzgün bir şekilde eklendiğini ve doğru yetkiye sahip olduğunu doğrulamak için basit bir test yazalım. yetenekler.

genel işlev testUser()

// setUp kullanıcısının istediğimiz sınıra sahip olduğundan emin olun

$kullanıcı = get_user_by('kimlik', $this->yazar->kimlik );

$this->assertTrue( user_can( $user, 'edit_posts' ), ​​'Kullanıcının edit_posts özelliği yok ve olmaması gerekiyor' );

$this->assertFalse( user_can( $user, 'activate_plugins' ), ​​'Kullanıcı eklentileri etkinleştirebilir ve bunu yapamamalıdır');

Yukarıda, oluşturduğumuz sahte kullanıcıya dayalı kullanıcı nesnesini alarak başlıyoruz. Bir sonraki olarakassertTrue veasserFalse ifadeleriyle yapacağımız yeteneklerimizi test etmek için bu nesneye ihtiyacımız olacak.

Bu örnekte iddiaTrue, user_can( $user, 'edit_posts' ) yöntemimizin true döndürmesini bekliyor. Sağlanan kullanıcı nesnesine, bir düzenleyicinin sahip olması gerektiği gibi, edit_posts yeteneğinin verildiğinden emin olmak için test yapıyoruz. Eğer bu false değerini döndürseydi, terminaldeki birim test çıktımızda verilen mesajı görürdük.

Daha sonra, aynı kullanıcının yönetici kullanıcı özelliklerine sahip olmadığından emin olmak için test yaparız. Burada active_plugins yeteneğini kontrol ederken iddiaFalse kullanıyoruz. Bu, false değerini döndürmelidir çünkü active_plugins`, Editörler için değil, WordPress'teki Yönetici rolü içindir.

SetUp işlevinizden sonra bu kodu ekledikten sonra terminale gidin ve phpunit'i çalıştırın. 3 iddiayla birlikte 2 testin tamam olduğunu görmelisiniz.

PHPUnit, testUser işlevimizi bir test olarak ve içindekiassertTrue/assertFalse ifadelerini de iddia olarak kabul eder.

Bu fabrika olayı ne anlama geliyor?

Burada bitirmeden önce dikkatinizi tekrar kurulum fonksiyonumuz üzerine çekeyim. Özellikle yeni bir kullanıcı oluşturduğumuzda fabrika bölümü.

WP CLI iskelesini kullandığınızda, aşağıdakilere erişmenizi sağlar: WP_UnitTest_Factory sınıfı. Bu sınıf, testlerinizi düzgün bir şekilde yürütmek için ihtiyaç duyacağınız verileri oluşturmanıza yardımcı olacak bir yardımcıdır. Bu fabrikayı WordPress Multisite için gönderiler, ekler, yorumlar, kullanıcılar, terimler ve başka şeyler oluşturmak için kullanabilirsiniz.

Ancak testlerinizde WordPress'i taklit etmek için kullanabileceğiniz tek araç bu değil. Gelecekteki bir gönderide ele alacağız WP_Mock WordPress'in yerleşik fabrikanın çok iyi ulaşamadığı kısımlarını test etmek için.

Bugün, WordPress projelerinizin birim testine bakarken oldukça karmaşık bir konuyu ele aldık. Birim testine başladığımda bunun göz korkutucu göründüğünü biliyorum, ancak işe yarayan ve bir şeyi bozduğunuzda size haber veren bir kod istiyorsanız buna değer, böylece müşterilerinizin sorunu sizin için bulmasına gerek kalmaz. Uzun vadede test edilebilir kod yazarak ve projelerinizde yeterli test kapsamını hedefleyerek zamandan ve baş ağrısından tasarruf edeceksiniz.

Güvenlikten ödün vermeden web siteniz büyüdükçe ölçeklenen, tam olarak yönetilen WordPress barındırma ile WordPress sitelerinizin performansını artırın. Bugün daha fazlasını öğrenin.