WordPress'te Birim Testine Giriş – AJAX Geri Aramaları

En sonunda! Bugün birim test serimizdeki son gönderiyi paylaşıyoruz. Önceki gönderileri okuduysanız (ve beğendiyseniz), tebrikler! Artık birim testlerinin ne olduğunu ve nasıl kullanılacağını, PHP kodunuzu PHPUnit ile nasıl test edeceğinizi ve JavaScript kodunuzu QUnit ile nasıl test edeceğinizi biliyorsunuz. Sadece üç gönderiyle çok şey öğrendik, değil mi? Ama yine de bir adım daha ileri gitmemiz ve yeni becerilerimizi gerçek dünyada “gerçek” bir örnekle test etmemiz gerektiğini düşünüyorum.

Bir önceki gönderide bahsettiğim gibi, bugün size “gerçek” bir eklentinin farklı bileşenlerini nasıl test edeceğinizi öğreteceğim. Özellikle, yoğun olarak AJAX kullanan bir eklentinin PHP ve JavaScript bileşenlerini nasıl test edeceğinizi göstereceğim.

Eklenti – Bir Gönderi Arayıcı

Bugün, yeni test becerilerinizi gerçek bir örnekle test etmenizi istiyorum. Bu nedenle, yapmamız gereken ilk şey, test edeceğimiz eklentidir – uygulamak için yeterince basit, ilginç testler oluşturmak için yeterince karmaşık.

Oluşturacağımız eklenti bir Post Searcher . Tüm gönderilerimizin sonuna ekleyeceğimiz basit bir formdan oluşur. Kullanıcı forma bir dize yazdığında, eklentimiz bir AJAX isteği gerçekleştirecek ve başlığı sorgu dizesini içeren tüm gönderileri kurtaracaktır. Bunun gibi bir şey:

arama kriterlerine uyan tüm gönderilerin bir listesi ile:

veya hiçbir gönderi bulunamadığında bir uyarı mesajı:

Oldukça kolay, değil mi? Kodlama zamanı!

1. İskelet

Bildiğiniz gibi, eklentinin kodunu istediğiniz gibi düzenlemekte özgürsünüz. Şahsen, (büyük) projelerime, WordPress Plugin Boilerplate tarafından sağlanan gibi sağlam bir iskeletle başlamayı seviyorum. Ancak bugün her şeyi basit tutmak istiyorum, bu yüzden sakıncası yoksa, tüm işlevleri tek bir PHP dosyasına ekleyeceğim – bu en zarif çözüm değil, ama işe yarıyor.

Eklentimizin ana dosyasını oluşturalım. İlk olarak, wp-content/ plugins / içinde nelio-post-searcher adında bir dizin oluşturun ve aşağıdaki içeriğe sahip nelio-post-searcher.php adlı bir dosya ekleyin:

Ve işimiz bitti! Hayır, şaka yapıyorum – az önce hiçbir şey yapmayan bir eklenti yarattınız. İlk geçersiz eklentiniz . Yaşasın!

Eklentimiz bir AJAX çağrısı uygulayacak, bu yüzden JavaScript kodumuzu içerecek dosyaları hazırlayalım. Eklentimizin kök dizininde iki boş dosya oluşturun: searcher.js ve functions.js .

Ve bu ilk adımı Panonuzdaki eklentiyi etkinleştirerek tamamlayın.

2. Arama Formunu Ekleyin ve JavaScript Dosyalarını Sıraya Alın

Formu yazılarımızın sonuna ekleyelim. WordPress kancalarıyla daha önce çalıştıysanız, aslında oldukça kolaydır: formu the_content adlı filtreyi kullanarak eklemeniz yeterlidir (belgelerini okuyun). PHP dosyanıza aşağıdaki parçacığı ekleyin:

Gördüğünüz gibi, yazının sonuna bir metin input ve bir sonuç div . Yine, bu en iyi çözüm değil ("mantık" ile "sunu"yu karıştırıyoruz), ancak işe yarıyor ve kolay. Bunu daha iyi uygulamak istiyorsanız, partials bir dizinde ayrı bir dosya oluşturmak ve onu fonksiyona dahil etmek isteyebilirsiniz… ama bu size kalmış, sevgili dostum!

Bu arama formunun AJAX çağrılarını kullanacağını söylediğimizi unutmayın, bu yüzden komut dosyalarımızı da eklememiz gerekiyor. Komut dosyalarını aşağıdaki gibi sıraya koymanız yeterlidir:

ve yepyeni, boş komut dosyalarımız ön yüzünüze eklenecektir.

3. Arama İşlevini Gerçekleştirin…

Şimdi arama fonksiyonunu uygulamamız gerekiyor. Başlığı belirli bir sorgu dizesi içeren gönderilerin "tümünü" almakla ilgileniyoruz; bu, aşağıdaki işlevin mükemmel olacağı anlamına gelir:

çünkü arama sorgusunu girdi parametresi olarak alır ve sonuçları içeren bir dizi döndürür. İşlevi yakından incelerseniz, WP_Query post_title__like adlı bir argüman kullandığını fark edeceksiniz, korkarım WordPress'te varsayılan olarak mevcut değil . Ekstra bir fonksiyonla oluşturalım:

Bu fonksiyona neden ihtiyacımız olduğunu merak ediyor olabilirsiniz. Pekala, varsayılan olarak WordPress'in arama işlevi, başlıklarında veya içeriklerinde sorgu dizesini içeren tüm gönderileri döndürür. Yalnızca başlıklarında eşleşen gönderileri bulmakla ilgilendiğimiz için bu ekstra parametreye ihtiyacımız var.

4. …ve Bu Fonksiyonu Kullanan AJAX Geri Çağırmasını Oluşturun

Yukarıdaki fonksiyon oldukça güzel. Belki düzgün çalışıyor bile… Ama bir yerde kullanmazsak hiçbir işe yaramaz! Öyleyse, JavaScript'ten kullanabilmemiz için bir AJAX geri çağrısı kullanarak onu açığa çıkaralım. Dosyanıza aşağıdaki parçacığı eklemeniz yeterlidir:

Bu yeni işlev, yalnızca AJAX isteğinde bir sorgu parametresi ( q adlı) olup olmadığını kontrol eder. Eğer mevcut değilse, bir hata döndürürüz. Varsa, arama fonksiyonumuzu kullanır ve sonuçları döndürürüz. Girdiyi kullanmadan önce sterilize ettiğimize dikkat etmek önemlidir; bu, kullanıcı tarafından sağlanan herhangi bir girdiyi kullanmadan önce her zaman yapmanız gereken bir şeydir.

Bu işlevin herhangi bir return deyimi olmadığını da belirtmekte fayda var; bu bir AJAX geri çağrısıdır ve bu nedenle, wp_send_json* kullandığımızda yürütmesi sona erer.

5. Biraz JavaScript Yazalım!

Sunucu tarafı kodumuz hazır! Kullanmak için biraz JavaScript yazalım, olur mu? Rebecca Murphey'in videosunu gördüyseniz, test edilebilir JavaScript kodunun nasıl yazılacağını zaten biliyorsunuzdur. Henüz görmediyseniz, bu yazıyı okumayı bırakın, hemen gidin görün, döndüğünüzde devam edeceğiz.

Şimdi yazmamız gereken kod, kullanıcı ile arama formu arasındaki etkileşimi tanımlar. Esasen, istediğimiz şudur:

• Kullanıcı arama alanına bir şey yazdığında, ona gönderilerini “aradığımızı” söylemeliyiz.
• Bitirdiklerinde, AJAX isteğini gerçekleştirmemiz ve eşleşen sonuçları kurtarmamız gerekiyor.
• Sonuçları aldıktan sonra ekrana çiziyoruz.
• Eğer yoksa kullanıcıya hiçbir şey bulamadığımızı söyleriz.
• Kullanıcı arama girişini temizlerse, sonuç alanını da temizleriz.

Farklı bir davranış veya farklı bir form uygulamak istiyorsanız, lütfen çekinmeyin. Bu gönderi, izleyebileceğiniz bir örnekte sunulan bir dizi yönergeden ibaret mi? Tıpkı PHP gibi, kodunuzu istediğiniz gibi yazıp düzenleyebilirsiniz. Ancak Rebecca'nın videosunda paylaştığı fikirleri uygulamaya karar verirseniz, şuna benzer bir searcher.js dosyası elde edebilirsiniz:

Çok fazla kod olduğunu biliyorum, ama göründüğünden daha kolay. İlk olarak, giriş alanındaki değişiklikleri dinleyen onQueryChanged adında bir fonksiyonumuz var ve kullanıcı yazmayı bıraktıktan sonra (bunu underscorejs.org'un _.debounce fonksiyonunu kullanarak simüle ediyoruz), adında bir sarmalayıcı fonksiyonu kullanarak sonuçları yüklemek için bir AJAX isteğini tetikliyoruz. searchPosts . AJAX isteği başarılı olduğunda, sonuçları, isteğin başarılı olup olmadığını kontrol eden processResult adlı bir işlevi kullanarak işleriz. Eğer öyleyse, sonuçları göstermek için draw işlevini kullanırız. Son olarak, kullanıcı metin girişini clear , sonuç alanını da temizleriz.

Şimdi bir gönderiyi yenilerseniz ve kodunuzun çalışıp çalışmadığını kontrol ederseniz, çalışmadığını göreceksiniz. Bunun nedeni, arama fonksiyonlarını basitçe yarattık, ancak henüz onları harekete geçirmedik. Bunu yapmak için, functions.js dosyanızda bir miktar "glue code" oluşturmamız gerekiyor:

Eklentimizi Test Etme

Son olarak, kodumuzu test etme zamanı! Bir süre önce benim gibiyseniz, muhtemelen kodu manuel olarak test edeceksiniz. Yani, tarayıcınızı açacak ve bazı verileri yazıp sonuçlara bakarak işlerin beklendiği gibi çalışıp çalışmadığını kontrol edeceksiniz. Ve, hey, test yaklaşımınız ne olursa olsun muhtemelen bunu yapmaya devam etmelisiniz… ama artık bazı birim testleri oluşturmanız gerektiğini de biliyorsunuz!

Son birkaç dakika içinde yaptığımız en büyük hata, hiçbir şeyi test etmeden çok fazla kod yazmış olmamızdır. Elbette, bunda çok iyi olduğumuzu biliyorum, ancak yeni kod eklerken bazı testler yazmak, (a) testlerin var olduğunu ve (b) önemli şeyleri test ettiklerini garanti edecektir.

Endişelenme, hala zamanımız var! Yazmış olabileceğimiz testin birkaç örneğini görelim.

PHPUnit ile PHP Testi

PHP kodumuzla başladığımızdan beri, ilk önce PHP'yi test etmek mantıklı, değil mi? Basit bir şeyle başlayalım – gönderilerimizin sonuna eklediğimiz formun gerçekten orada olduğundan emin olalım:

Yukarıdaki test, test ortamımızda daha sonra kullanabileceğimiz bir gönderi oluşturur. Gönderi oluşturulduktan sonra onu alır ve içeriğine bakarız ( the_content filtresini uyguladıktan sonra). Formumuz başarıyla eklendiyse, içerik , metin girişimizin ve sonuç div'imizin kimliklerini içermelidir – ve biz de tam olarak bunu iddia ediyoruz. Tereyağından kıl çeker gibi!

Ayrıca JavaScript betiklerimizin ön uca başarıyla dahil edilip edilmediğini de kontrol etmek isterim. Ama, hey, sen bununla ilgilen! ?

Ardından, eklentimizdeki en önemli işlevin – arama sonrası işlevi – beklendiği gibi çalıştığından emin olmamız gerekiyor. Bu “beklenen davranışın” ne olduğuna karar vermek size kalmış ve kararlarınıza bağlı olarak bir şeyi test etmeniz gerekiyor. Örneğin, aşağıdaki senaryolarda işlev nasıl yanıt vermelidir?

• Sorgu dizesi boşsa ne olur?
• WordPress'te hiç yazı yoksa ne olur?
• Kriterlere uyan herhangi bir gönderi yoksa, işlev ne döndürür?
• Birden fazla gönderi kriterlerle eşleşirse ne olur?

Dediğim gibi, burada neyin doğru neyin yanlış olduğuna karar verecek olan sensin . Tüm bu senaryoları düşündüm ve aşağıdaki beklenen davranışları buldum (ki zaten bir testte kodladım):

Son olarak, AJAX çağrısının beklendiği gibi çalıştığından emin olmamız gerekiyor. Arama fonksiyonunu önceki testte zaten kapsamlı bir şekilde test ettiğimiz için, bu fonksiyonda test edilecek pek bir şey yok—sadece geri aramanın giriş parametreleriyle düzgün bir şekilde ilgilendiğinden emin olmamız gerekiyor. Örneğin, herhangi bir sorgu sağlanmazsa işlevin bir hata döndürmesini istediğimizi söyledik ve eğer öyleyse bir gönderi listesi:

Bu testte dikkat edilmesi gereken iki ilginç şey var. İlk olarak, test WP_Ajax_UnitTestCase adlı bir sınıftan miras alır. Bu sınıf, try-catch bloğunda görebileceğiniz gibi, AJAX isteklerini simüle etmemize izin veriyor. İkincisi, döndürülen gönderi listesinin doğru olduğunu doğrulamak için herhangi bir test eklemedik— neliops_search_posts işlevini test ederken bunu zaten test ettik, öyleyse neden işimizi tekrar edelim?

İşimiz bittiğinde PHPUnit'i başlatıyoruz ve…

BOOM! Uçan renkler! çiviledik mi? Çak beşlik!

JavaScript'i QUnit ile test etme

Test etmemiz gereken son şey, tahmin edebileceğiniz gibi JavaScript kodumuz. Akılda tutulması gereken en önemli şey , AJAX uç noktanızın beklendiği gibi çalışıp çalışmadığını kontrol etmenin sizin sorumluluğunuzda olmadığıdır – tüm sunucu çağrılarınızın beklendiği gibi çalıştığını varsaymalısınız (bu durumda, onları zaten test ettik). Aslında, yine de gerçek geri aramaları kullanmamalısınız – verileri taklit etmeli ve kodunuzu onunla test etmelisiniz.

En kolay örneğe bir göz atalım! Kodumuz gönderilerin listesini doğru şekilde çiziyor mu? Aşağıdaki testler geçerse kesinlikle olur:

Ne kadar kolay olduğunu görüyor musun? Kodumuz birkaç yalıtılmış işlev kullandığından, bunları tek tek test etmek kolaydır; her işlevin açık bir sorumluluğu vardır ve testleri de öyle! Şimdi anonim işlevleri kullanıp spagetti kodu yazsaydınız ne olacağını hayal edin.

Diğer testler ne olacak? AJAX sonuçlarını doğru şekilde işliyor muyuz? Formda herhangi bir metin olmadığında sonuç alanı düzgün bir şekilde temizleniyor mu? Yazabileceğin bir sürü test var! cesaretin var mı

Sonuçlar

Ve paylaşmak istediğim tek şey bu millet! Tüm yazılarımı okuduğunuz için teşekkürler? Bugün yeni edindiğimiz becerilerimizi test ettik. Bileşenlerimizi tek tek test etmek ve beklendiği gibi davranmalarını sağlamak için birim testlerini nasıl kullanacağımızı öğrendik. Birlikte nasıl çalıştıklarını test edecek olsaydık, entegrasyon testleri oluşturmamız gerekirdi (bu serinin kapsamı dışındadır).

Şimdi, son bir soru: Önce testleri yazabilir (hiç kod olmadan), çalıştırabilir (ve başarısız olduklarını görebilir) ve ardından testlerin geçmesi için kodu yazabilir misiniz? Eğer öyleysen, tebrikler! Artık Test Odaklı bir Geliştiricisiniz. Denemenizi ve deneyimlerinizi bizimle paylaşmanızı şiddetle tavsiye ederim.

Mutlu yıllar!

Öne Çıkan Resim Yosuke Muroya tarafından.