WordPress Eklentilerinde Birim Testi Ajax ve API İstekleri

Birim testinden korkuyorum. İşte, söyledim. Birim testi, yapmam gerektiğini bildiğim uygulamalardan biri, yapmanın faydaları var, ancak özellikle yerleşik bir kod temeli ile uygulanması çok zor görünüyor.

Son zamanlarda bir sonraki eklentimizi oluşturuyordum ve geliştirmesi boyunca kafamda sürekli olarak birim testlerini hatırlatan rahatsız edici bir ses vardı. Bu yüzden daldım ve testler yazmaya başladım. Bu yazıda, bir kılavuz olarak son deneyimlerimi kullanarak bir WordPress eklentisini test etmeyi tanıtacağım.

Birim Testi Nedir?

Bunu bir an önce çözelim: birim testi, doğru çalıştıklarından emin olmak için genellikle işlevler ve yöntemler olmak üzere en küçük kod birimlerini test etme uygulamasıdır. Tipik olarak bu, verileri belirli bir senaryo için bir yönteme iletmek ve sonuç veya dönüş verilerinin beklendiği gibi olmasını sağlamak anlamına gelir.

Birim testi aslında oldukça basittir, bu da beni başlangıçta yapmaktan alıkoyan ana yanılgılarımdan biriydi. Örnek olarak WP Boşaltma S3'ü alın. Eklenti, dosyaları Amazon S3'e yükler. Doğru, ne kadar test etmeliyim?

Yükleme yöntemini test ederken, yükleme gerçekleştirildikten sonra test, dosyanın S3'te var olup olmadığını gerçekten kontrol etmeli mi? Hayır, olmamalı. Test, Amazon Web Services API'sini hiç kullanmamalı, ancak buna daha sonra geleceğiz.

Test Kurulumu

WP-CLI, yerel olarak eksiksiz bir WordPress birim test ortamı kurmanın en iyi yoludur. Bir ön koşul, PHP uygulamalarını birim testi için fiili çerçeve olan PHPUnit'tir. WP-CLI, test sırasında eklentiyi ve kitaplığı yüklemek için WordPress test kitaplığını ve bir dizi yapılandırma dosyasını yükleyecektir.

Test kitaplığının en önemli özelliklerinden biri WP_UnitTestCase sınıfından uzanan PHPUnit_Framework_TestCase sınıfıdır. Yazdığınız her test senaryosu, WordPress ortamını her testten önce hazırlama ve her testten sonra temizleme konusunda çok yararlı işlevler sağladığından, onu genişletmelidir.

WP_UnitTestCase , tipik WordPress nesnelerini hızlı bir şekilde oluşturmak için son derece yararlı olan WP_UnitTest_Factory nesnesinin bir örneğini de gösterir. Örneğin, bir gönderiye bazı meta veriler ekleyen bir yöntemi test ediyorsanız, o gönderiyi sıfırdan oluşturma konusunda endişelenmenize gerek yoktur. Testiniz şöyle görünür:

 function test_add_meta() { $post = $this->factory->post->create_and_get(); MyClass::add_meta( $post->ID ); $expected_meta_value = 'Foo'; $this->assertEquals( $expected_meta_value, get_post_meta( $post->ID, 'test_meta_key' ) ); }

Unutmayın, WP-CLI'nin test ortamı kurulumu, kutudan çıkar çıkmaz mükemmel bir şekilde çalışmasına rağmen, eklenti ve testlerinizin gereksinimlerine uyacak şekilde özelleştirilebilen ve ayarlanabilen bir iskeledir. WP Migrate DB Pro için birim test ortamımızı nasıl kurduğumuzla ilgili Ian'ın makalesine göz atın.

Test Alanları

Eklentilerdeki WordPress kodunun ilk bakışta test edilemez gibi görünen bazı yönleri vardır. Ajax geri aramalarını ve API isteklerini nasıl test edersiniz? WordPress'in kendi temel işlevleriyle etkileşime ne dersiniz? İşte geçmişte beni geride tutan sorunlu alanlardan bazıları ve bunları nasıl test edeceğimiz.

Alaycı

Daha önce Amazon Web Services API ile iletişim kuran WP Offload S3'ün test edilmesinden bahsetmiştim. API kullanan bir sınıfı test ederken, sadece o sınıfı ve yöntemlerini test etmem gerekiyor. Testlerin API, AWS ve hatta HTTP ile ilgisi yoktur. Ayrıca, Amazon kendi API'leriyle ilgili sorunlar yaşıyorsa testlerinizi nasıl gerçekleştirirsiniz?

Test Çiftleri ve Alaycılığın devreye girdiği yer burasıdır. Testlerimin kullanacağı API sınıfından miras kalan kısmen alaylı bir sınıfa sahip örnek bir test durumu. Test setUp() yöntemi, testler arasında paylaşılan kodu depolamak için harikadır:

 function setUp() { $this->api = $this->getMockBuilder( '\DeliciousBrains\Offload\AWS\API' ) ->setConstructorArgs( array( API_KEY, API_SECRET ) ) ->setMethods( array( 'request' ) ) ->getMock(); $this->wp_error_response = new \WP_Error( 100, 'Issue with AWS' ); }

Sahte oluşturucuda setMethods kullanmak, yalnızca bu yöntemlerin taklit edildiği, yöntemlerin geri kalanının normal şekilde çalışacağı anlamına gelir. Bu yönergeyi atlarsanız, tüm yöntemler null değerini döndürür.

Ayrıca biraz sonra kullanılacak bir WP_Error tutmak için bir özellik ekledim. API sınıfı, AWS'den dosyaları döndürmesini isteyen get_files() adlı bir yönteme sahiptir. Başarılı olduğunda, yöntem bir dizi dosya döndürmelidir ve bir şeyler ters gittiğinde bir WP_Error . İşte bu yöntemin testi:

 $successful_response = new \stdClass; $successful_response->data = array( array( 'id' => 1, 'name' => 'image.jpg' ) ); $this->api->expects( $this->any() ) ->method( 'request' ) ->will( $this->onConsecutiveCalls( $successful_response, $this->wp_error_response, array() ) ); // Test for successful response $this->assertEquals( $successful_response, $this->api->get_files() ); // Test for WP_Error (Error) response $this->assertTrue( is_wp_error( $this->api->get_files() ) ); // Test for empty array response $array_response = $this->api->get_files(); $this->assertTrue( is_array( $array_response ) ); $this->assertCount( 0, $array_response );

Temel olarak request() yönteminden gelen dönüşü taklit ediyoruz ve yöntemimizin üç senaryoyu da doğru bir şekilde işlediğinden emin oluyoruz. onConsecutiveCalls() kullanarak, yöntemin birden çok çağrısı için farklı dönüş değerleri sağlayabilirsiniz. Oldukça havalı değil mi? Dış etkenlere, sistemlere veya hizmetlere bağımlı olmadan yalnızca kodumuzun birimini test ediyoruz.

Tam örnek test durumu burada:

Ajax

Ajax birim testi, ha? Bu Javascript'i içermeyecek mi? Tıpkı HTTP istekleri gibi, birim testlerimiz de Javascript tetikleme istekleri gibi bir şeyle ilgilenmez, bunun yerine bu istekleri taklit edebiliriz. WordPress test kitaplığı, Ajax geri aramalarını test etmeyi çok kolaylaştırır ve admin-ajax.php ile herhangi bir manuel alay etme gereksinimini ortadan kaldırır.

Test durumlarımızın WP_Ajax_UnitTestCase sınıfını genişletmesi gerekir ve önemli yöntem, aşağıdaki gibi bir Ajax eylem kancasının tetiklenmesiyle alay eden _handleAjax() yöntemidir:

 add_action( 'wp_ajax_as3cfpro_initiate_upload', array( $this, 'ajax_initiate_upload' ) );

Yani testin içinde $this->_handleAjax( 'as3cfpro_initiate_upload' ); geri aramayı tetiklemek için, ancak dikkate alınması gereken birkaç şey daha var. Geri aramanın ne döndürdüğüne veya bittiğinde ne aradığına bağlı olarak, test senaryonuzu nasıl oluşturduğunuz konusunda bilgi verir. Bu örnekte, geri arama wp_send_json_success aracılığıyla bazı JSON verilerini döndürür, bu nedenle çıkmadan önce bu verileri yakalamamız ve doğrulamamız gerekir:

Geri çağırmak:

 function ajax_initiate_upload() { check_ajax_referer( 'initiate-upload' ); … wp_send_json_success( 'Upload initiated' ); }

Test durumu:

 function test_ajax_initiate_upload() { // Spoof the nonce in the POST superglobal $_POST['_wpnonce'] = wp_create_nonce( 'initiate-upload' ); try { $this->_handleAjax( 'as3cfpro_initiate_upload' ); } catch ( WPAjaxDieStopException $e ) {} $response = json_decode( $this->_last_response ); $this->assertInternalType( 'object', $response ); $this->assertObjectHasAttribute( 'success', $response ); $this->assertTrue( $response->success ); $this->assertObjectHasAttribute( data, $response ); $this->assertEquals( 'Upload initiated', $response->data ); }

Bu makale, çeşitli geri arama dönüşleri ve bunların Ajax testlerinizde nasıl ele alınacağı hakkında daha fazla ayrıntıya girer.

Kodunuzu Daha İyi Hale Getirmek

Birim testi, kodla ilgili sorunları olduğu anda yakalamak için harikadır, ancak kod tabanına birim testleri ekleyerek gördüğüm önemli bir fayda, kodun kendisini şekillendirmeye ve iyileştirmeye nasıl yardımcı olduğudur.

Belirli sınıfları aşırı uzun ve karmaşık yöntemlerle test ederken, bu yöntemlerin yeniden düzenlenmesiyle birlikte testler yazılarak daha sürdürülebilir ve yeniden kullanılabilir kod elde edildi.

Diğer geliştiricilerle projeler üzerinde çalışıyorsanız, bu testleri Travis CI gibi bir araçla otomatik hale getirmek, sürekli değişen kod tabanında ortaya çıkabilecek sorunların üstesinden gelmenize yardımcı olacaktır.

TDD

alternatif birim testini ertelemek geriye dönük olarak bir grup birim testi yazmak, TDD'nin karanlık sanatını uyguluyor: Teste Dayalı Geliştirme. TDD, başarısız testler yazma ve ardından testi geçmek için yeterli kod yazma döngüsü ile ilgilidir. Her yineleme, teste daha fazla eksik işlevsellik ekleyecektir, bu daha sonra eklenecek ve mevcut koda yeniden yansıtılacaktır.

Carl Alexander, okumanızı tavsiye ettiğim, TDD odaklı WordPress'te birim testine harika bir giriş yazdı. Dürüst olmak gerekirse, TDD hakkında ne kadar çok okursam, özellikle yeni özellikler için onu uygulamaya o kadar çok başlamak istiyorum. Ayrıca, TDD aracılığıyla veya yalnızca test yazmaya adanmış olarak, ilerledikçe test etmek, tek bir büyük vuruşta eksiksiz bir kod tabanı için testler yazmaktan daha iyi olmalı ve kodunuzla ilgili sorunları bulmada reaktif olmaktan ziyade proaktif olmalıdır.

Umarım bu, WordPress eklentileri için birim testi konusunda yararlı bir fikir olmuştur ve kodunuz için testler yazmaya başlamayı biraz daha kolaylaştırmıştır.

Birim test maestrosu musunuz? WordPress ile ilgili test ipuçlarınızı aşağıdaki yorumlarda paylaşın.