WordPress Eklenti Testini Otomatikleştirmek için Codeception'ı Kullanma

Eklentilerimizden biri için yeni bir güncelleme yayınlama zamanı geldiğinde, Delicious Brains ekibi müşterilerimize daha fazla özellik ve iyileştirme sunmaktan heyecan duyar, ancak aynı zamanda başka bir manuel ve titiz turun başlangıcını işaret ettiği için biraz üzülür. test yayın! Son zamanlarda bu test sürecini en iyi nasıl iyileştirebileceğimizi tartışıyorduk ve bir seçenek de otomasyon. Bugün yaptıklarımızdan ve yavaş yavaş uygulamaya çalıştıklarımızdan bahsetmeme izin verin.

Serbest Bırakma Test Rölesi

Genel olarak, sürüm testine (kabul testi olarak da bilinir) 3 kişilik bir test rölesi olarak yaklaşırız. Mevcut kurulumumuz, her bir eklenti ve eklenti için çalışma sayfalarıyla birlikte her ürün için bir Google e-tablosu içerir. Her sayfada, eklentilerin işlevselliğini ve uç durumlarını kapsayan, gerçekleştirilecek çok sayıda test komut dosyası vardır.

İlk kişi komut dosyalarını test eder ve herhangi bir sorunu bulur. Bir sorun bulunursa, test başarısız olarak işaretlenir ve düzeltilmesi için GitHub'da yükseltilir. Röledeki bir sonraki kişi, yalnızca ilk kişi bitirdikten ve sorunlar düzeltildikten, test edildikten ve birleştirildikten sonra test turuna başlayabilir. İşlem, üçüncü kişi tam olarak test edene ve herhangi bir hata bulunmayana kadar tekrarlanır.

Bu test yaklaşımı çok kapsamlıdır ancak son derece zaman alıcıdır. Özel bir test kaynağımız yok, bu nedenle testler kendi içinde oldukça maliyetli olan ekip üyelerimiz (tüm geliştiriciler) tarafından gerçekleştirilir. Elbette testin kalitesi yüksektir ve bu fayda her zaman zaman ve maliyetten daha ağır basmıştır. Bununla birlikte, küçük bir ekip olarak, ürünlerimizi geliştirmek ve ara sıra yenilerini oluşturmak için kaynakları serbest bırakmak için her zaman süreçlerimizi iyileştirmenin, otomatikleştirmenin ve iyileştirmenin yollarını arıyoruz.

Ian'ın daha önce yazdığı test sürecimiz, PHPUnit kullanılarak yazılan ve Travis CI tarafından her kod GitHub depolarımıza gönderildiğinde çalıştırılan birim testlerini de içerir. Bu, son derece otomatik olduğu ve ürünler sürüm testi aşamasına geçmeden önce kodla ilgili sorunları yakaladığı için harika. Ancak birim testi, test bulmacasının yalnızca bir parçasıdır; eklentinin nasıl çalıştığını ve ne yaptığını test etmek için hala gerçek insanlara ihtiyacımız var. Bunu otomatikleştiremezsin, değil mi?

kod algılama

Codeception, kabul, işlevsellik ve birim testini otomatikleştiren davranışa dayalı bir test çerçevesidir. Testler PHP'de yazılır (çerçeve aslında PHPUnit üzerine kuruludur), Behat'a benzer şekilde açık ve açıklayıcı bir şekilde.

İlgilendiğimiz, Codeception'ın kabul testi bölümüdür. Genellikle eklentilerimizi kullanan bir kişi tarafından gerçekleştirilen testleri otomatikleştirmemize olanak tanır. Varsayılan olarak Codeception, 'PhpBrowser' dediklerini kullanır:

bir tarayıcı gibi davranan bir PHP web kazıyıcı: bir istek gönderir, ardından yanıtı alır ve ayrıştırır. Codeception, HTML web sayfalarıyla etkileşim kurmak için Guzzle ve Symfony BrowserKit'i kullanır.

PhpBrowser, hangi UI öğelerinin tıklanabileceği konusunda bazı sınırlamalara sahiptir ve JavaScript etkileşimlerini işlemez. Ancak, kabul testleriniz bunun yerine bir tarayıcı otomasyon aracı olan Selenium WebDriver'dan yararlanan WebDriver modülü kullanılarak çalıştırılabilir, böylece testleriniz tarayıcıda (tipik olarak Firefox) kendinizi test ediyormuşsunuz gibi etkileşime girebilir. Kulağa hoş geliyor değil mi? Bir şeyler ayarlamaya bir göz atalım.

Kurulum

Codeception'ı eklentilerimizi test etmek için kullanmaya yeni başladık ve AWS eklentilerimiz için deponun bir dalında çalışan birkaç test senaryomuz var. Bunu ayarlarken bulduğumuz şey, ortamın kurulumu ve konfigürasyonunun en çok zaman aldığı, ancak test yazmanın çok daha hızlı olduğuydu.

PHPUnit gibi, Composer kullanarak depomuzda Codeception yüklü:

 "require": { "codeception/codeception": "2.1.*", }

Codeception sitesi başlamayı benim yapabileceğimden daha iyi kapsadığı için kurulum ve yapılandırma hakkında daha fazla ayrıntıya girmeyeceğim.

Ayrıca Codeception için bir dizi WordPress uzantısı olan WPBrowser yüklü. WPBrowser modülü, test 'aktörünün' bir WordPress sitesiyle kolayca etkileşime girmesine izin veren çok yararlı yöntemler ekler.

Aşağıdaki örnekte, Amazon S3 ile etkileşime giren WP Offload S3 Lite eklentimizin bir senaryosunu test edeceğiz. Kodun tek başına test edildiği birim testlerinin aksine, bu kabul testlerinin dosyaların S3'e yüklenip yüklenmediğini doğrulaması gerekir. Amazon'un S3 konsol sayfasını kontrol ederek S3'te dosyaların olup olmadığını see için WebDriver modülünü kullanabiliriz, ancak konsol gerçek hayattaki kullanıcılar için harika olmadığından, Selenium'un her seferinde erişmesine güvenmek istemem. Bunun yerine Codeception için S3 verileri hakkında iddialarda bulunmak için AWS API'sini kullanan bir S3 dosya sistemi modülü oluşturdum.

Çevre

Test WordPress sitesini kurmak için WPBrowser'ın WPLoader modülünü kullanmak yerine, kabul testlerimizi çalıştırmak için gereken her şeyi kurmak için kendi bash betiğimizi kullanmaya karar verdik. Komut dosyası WP-CLI'ye dayanır ve şunları içerir:

1. WordPress'i depomuzdaki bir tmp dizinine kurmak (.gitignored elbette)
2. Eklentilerimizi kaynaktan oluşturun ve siteye yükleyin
3. PhantomJS veya Selenium'u indirin ve WebDriver modülü tarafından kullanılmak üzere çalıştırın.
4. Codeception testlerini çalıştırın
5. PhantomJS veya Selenium'u kapatın
6. Herhangi bir Firefox örneğini öldür

Bir örnek

WP Boşaltma S3'ü test ederken yaptığımız her şeyi gösteren bir örnek depo oluşturdum, ancak bunu daha ince bir formda yaptım.

Kurulum

README.md'de ayrıntılı kurulum adımları ile proje için birkaç gereksinim vardır.

Hepsi yüklendikten sonra, sh run-tests.sh çalıştırarak testi başlatabilirsiniz.

Senaryo

Bu örneğin kalbinde, belirli bir senaryo için tüm adımları ve iddiaları içeren bir dosya olan 'cept' olarak bilinen ana test dosyası bulunur. Senaryomuz, WP Offload S3 Lite'ın temel işlevselliğini test etmektir – WordPress Medya Kitaplığına bir dosya yükleyin ve S3'e boşaltıldığından emin olun:

 <?php $I = new AcceptanceTester( $scenario ); // Login to wp-admin $I->loginAsAdmin(); // Navigate to the Media Library $I->amOnPage( '/wp-admin/media-new.php' ); $I->waitForText( 'Upload New Media' ); // Add new file $I->attachFile( 'input[type="file"]', 'team.jpg' ); // Wait for upload $I->waitForElement( '.edit-attachment', 20 ); $I->seeElement( '.edit-attachment' ); $I->click( '.edit-attachment' ); // Navigate to the Edit Media window $I->executeInSelenium( function ( \Facebook\WebDriver\Remote\RemoteWebDriver $webdriver ) { $handles = $webdriver->getWindowHandles(); $last_window = end( $handles ); $webdriver->switchTo()->window( $last_window ); } ); $I->waitForText( 'Edit Media' ); // Check URL is an S3 one $url = $I->grabValueFrom( 'attachment_url' ); $this->assertContains( 'amazonaws.com', $url ); // Parse the URL $url = explode( '.com/', $url ); $url_parts = explode( '/', $url[1] ); $bucket = array_shift( $url_parts ); $key = implode( '/', $url_parts ); // Check attachment has been offloaded to Amazon S3 $I->setBucket( $bucket )->seeFile( $key );

Adımlar, insan tarafından oldukça okunabilir ve gerçek bir test kullanıcısının yapacağını tekrarlayan süreci açıkça gösterir: oturum açın, medya kitaplığına bir dosya ekleyin, URL'nin bir S3 URL'sine yeniden yazıldığını kontrol edin ve son olarak AWS ile kontrol edin. dosya yüklendi.

Codeception ve Selenium'un bu senaryonun test edilmesini otomatikleştirmesini izlemek oldukça havalı:

tartmak

Bunların hepsini kurmak için kesinlikle önemli miktarda çalışma var. Eklentimizin işlevselliğini tam olarak test etmek için özel bir S3 modülü bile yazmam gerekti ve özel işlevsellik ihtiyacı, ne yaptıklarına bağlı olarak herkesin eklentileri için aynı olabilir. Ayrıca iyileştirme için yer var. Senaryoyu yalnızca WordPress'in tek bir site yüklemesi için test ediyoruz, ancak mevcut sürüm testi sürecimiz, WordPress multisite'nin hem alt etki alanını hem de alt dizin özelliklerini kapsar. Test sırasında veritabanları ve kurulumlar arasında geçişi olabildiğince ağrısız hale getirmek için Codeception için özel bir veritabanı modülünün gerekli olduğunu varsayardım.

Kod ve ürün işlevselliği zamanla değiştiğinden, komut dosyası bakımına da ihtiyaç vardır. Elbette bu, birim testleri için aynıdır, ancak kabul testi senaryoları için daha fazla dahil olabilir. Tüm bunları göz önünde bulundurarak, insan test cihazlarımızdan ikisini potansiyel olarak Codeception kullanarak otomatik testlerle değiştirme yeteneğine sahip olmanın, yayın testi sürecimiz için nihayetinde faydalı olacağına kesinlikle inanıyorum. Test etme süresi, geliştirici süresinin (ve ruh halinin!) azalması gibi ciddi şekilde azalacaktır.

Umarım yakın gelecekte test senaryolarımızı oluşturmaya ve Codeception'ı test sürecimize tam olarak entegre etmeye başlayabiliriz. Ürünleriniz üzerinde kabul testi yapıyor musunuz? Codeception veya başka bir araçla bunları otomatikleştirmeye başladınız mı?