Teknoloji Pazarlama, Bloglarınızdan ve Gadget'larınızdan Para Kazanın

WordPress Birim Testi Jargonunu Anlamak

WordPress Birim Testi Jargonunu Anlamak

Son gönderimizde, kodunuzu WordPress'te test etmeye temel bir bakış attık. Bugün, WordPress için birim testi hakkında konuştuğunuzda ortalıkta dolaşan tüm jargonu size tanıtarak (ve anlamanıza yardımcı olarak), iyi test edilmiş kod yazma yolunda bir adım daha atacağız.

Test Türleri

Evet, uygulamamız için sahip olabileceğimiz test türleri yalnızca birim testleri değildir; bu nedenle, çalışmanızda kullanabileceğiniz farklı test türlerine bakalım.

Birim Testleri

Bu tür testler bir test sisteminin ilk aşamasıdır. Yazdığınız kodun beklendiği gibi çalıştığından emin olmak için özellikle test yaparlar. Birim testleri testlerinizin temelini oluşturur çünkü kodunuz düzgün çalışmıyorsa sonraki test türleri sallantılı bir temel üzerine kurulur.

İki haftadan daha eski gönderiler için kalıcı bağlantıların düzenlenmesini site yöneticileriyle sınırlamak istersem, birim testim, doğru türde bir kullanıcıya ve doğru tarihe sahip bir gönderiye sahip olduğumdan emin olmak için WP_Mock'u kullanır. Daha sonra fonksiyonumun beklenen doğru veya yanlış değeri döndürdüğünden emin olurdum.

Birim testlerinin yazdığınız kod dışında hiçbir bağımlılığı olmamalıdır. Başka hiçbir sistemle etkileşime girmemelidirler. Bu, son gönderimizin gerçek bir birim testi olmadığı, bir entegrasyon testi olduğu anlamına geliyor çünkü kullanıcımızı oluştururken veritabanıyla etkileşime girdik.

Birim testlerini çalışmanızın temeli olarak kullandığınızda, her yöntemin/fonksiyonun tek bir sorumluluğa sahip olmasını sağlamaya yardımcı olursunuz çünkü tek bir fonksiyona daha fazla koşul ekledikçe test edilmesi giderek zorlaşır.

WordPress projelerinde birim testi yaparken karşılaşacağınız araçlardan bazıları şunlardır:

Entegrasyon Testleri

Bu, işinizde yapacağınız ikinci test türüdür. Entegrasyon testleri, iki sistem arasındaki etkileşimlerin beklendiği gibi çalıştığından emin olur. Birim testlerinden farklı olarak buradaki amaç birden fazla sistem arasındaki etkileşimi görmektir.

WordPress'in kendisi birim testlerinden daha fazla entegrasyon testi yapıyor çünkü uygulamanın çoğu yazıldığında en iyi uygulamalar farklıydı. WordPress'in içindeki işlevler birçok yeni PHP CMS'den çok daha büyüktür ve çok daha fazla iş yapar. Bu daha büyük işlevlerin düzgün bir şekilde birim testi yapması zordur çünkü çok fazla şey yaparlar. Bu, kodumuzun doğrudan WordPress ile nasıl çalıştığını kontrol ederken entegrasyon testlerine daha fazla güvendiğimiz anlamına gelir.

Okumak:  Farklı Araştırma Alanlarını Keşfetmek: Genel Bir Bakış

Bunların hiçbiri kötü değil, sadece testlerin şimdiki kadar yaygın olduğu dönemde geliştirilmemiş bir uygulamanın ürünü.

Entegrasyon testine başka bir örnek, bir e-posta pazarlama platformuyla entegrasyon oluşturuyor olmanız olabilir. E-postayı doğru şekilde doğruladığınızdan ve formu beklendiği gibi gönderdiğinizden emin olmak için birim testlerini kullanabilirsiniz. Geçerli e-postanızı e-posta platformuna gönderdiğinizde yanıtla doğru şekilde ilgilendiğinizden emin olmak için entegrasyon testleri kullanılacaktır.

Entegrasyon testi için araçlar:

Mutasyon Testi

Mutasyon testi yalnızca halihazırda bir tür test kapsamına sahip olan projeler için kullanılacaktır. Bu tür testler, yaygın kodlama hatalarını ortaya çıkararak kodunuzun “mutantlarını” oluşturur. Amaç, bu hatalar ortaya çıktığında birim testlerinizin bozulmasıdır, bu da mutantı yakalayıp öldürdüğünüz anlamına gelir. Mutasyon testi araçları, kaç tane mutant öldürdüğünüz ve mutantları yakalamadığınız yerler hakkında rapor verecektir.

Mutasyon testi, test kapsamınızın kalitesini ölçmek için kullanılabilir. Eğer %100 test kapsamının yanı sıra çok sayıda mutantınız varsa, büyük bir sorununuz var demektir. Bu, testlerinizin programcıların yaptığı yaygın hataları yakalayamadığı anlamına gelir. Kod kırılması gerçekleşmeyi bekliyor.

Esasen, testlerinizi test ediyorsunuz.

Mutasyon testi için araçlar:

Kabul testleri

Bunlara fonksiyonel test veya tarayıcı testi de denilebilir. Birim testlerinin kodunuzla başlayıp dışarıya doğru çalıştığı durumlarda, kabul testleri yazılımınızı kullanan kişinin görüşünü alır. Kabul testleriyle, kullanıcıların görmeyi beklediklerini görmelerini sağlamak için web tarayıcısını sitenizle etkileşime girecek şekilde otomatikleştirebilirsiniz.

Kabul testlerinin sürdürülmesi daha zordur çünkü yazılımınızın kullanıcı arayüzündeki küçük bir ifade değişikliği, otomasyonun bulmayı beklediği kullanıcı arayüzü öğelerini artık bulamaması nedeniyle testin bozulduğu anlamına gelebilir. Bu nedenle, alışveriş sepetinizdeki ödeme süreci gibi yalnızca iş açısından kritik altyapılara yönelik kabul testlerine yatırım yapın.

Kabul testi için araçlar:

Jargon

Artık yapabileceğiniz test türlerini ele aldığımıza göre, geliştiricilerin testleri yazarken kullanacakları diğer dili anladığımızdan emin olmamız gerekiyor.

Çift Testi

Dönem çiftler testi test amacıyla bir üretim nesnesini/işlevini/şeyini değiştirdiğiniz zamanı ifade eden genel bir terimdir. Bunu, üretim veritabanımızda bulunmayan bir kullanıcıyı eklemek için WP_UnitTestCase'i kullandığımızda WordPress'te Birim Testine Başlarken başlıklı önceki yazımızda yaptık. Bunu, işler tehlikeli hale geldiğinde oyuncunun “yerini alan” bir dublör gibi düşünmek faydalı olabilir. Test, testi kolaylaştırmak için verilerimiz ve kodumuz için “yedek” işlevi görür. Üretimdeki benzerleri gibi görünmeli ve davranmalıdırlar, ancak test ederken karmaşıklığı azaltmak için basitleştirilmelidirler.

Okumak:  2024'te Kullanılacak En İyi 9 WordPress Geri Bildirim Eklentisi

Sahte

API veya veritabanıyla etkileşimde bulunmak istemediğinizde taklitler kullanılır. Veritabanının karmaşıklığını artırmadan tek bir kod birimini test edebilmek için sahte veritabanı etkileşimleri kullanırsınız.

Bir sahtenin veritabanındaki veriler olması gerekmez. Gibi bir araç WP_Mock WordPress içindeki kanca sistemini taklit etme yeteneğine sahiptir. Bu, WordPress ile etkileşime girmenize gerek kalmadan işlevinizde bir kancanın çağrılıp çağrılmadığını test etmenizi sağlar.

Aşağıda WP_Mock'ta get_permalink işlevini taklit ettiğimiz bir örneği görebiliriz. Fonksiyonun kaç kez çağrılmasını beklediğimizi, beklediğimiz argümanları ve döndürülmesini beklediğimiz değeri sağlarız.

\WPMock::userFunction( 'getpermalink', array(

'argümanlar' => 42,

'kere' => 1,

'dönüş' => 'https://theanswertoeverything.fourtytwo/guide

Gelecekteki bir gönderide WP_Mock'un nasıl kullanılacağını ele alacağız.

Taslaklar

Taslaklar, testimizin sorabileceği soruların hazır yanıtları gibi, testlerimiz için sabit kodlanmış değerlerdir. Testinize, testi çalıştırırken bir kullanıcının oturum açtığını varsayma talimatını vermiş olsaydınız bir saplama kullanıyor olurdunuz. Başka bir test, kullanıcının oturumu kapattığını varsayabilir. Her iki test de işlevlerinizin kodunuzdaki belirli dal için uygun değerleri döndürdüğünden emin olacaktır.

Taslakları ve taklitleri birlikte kullanmanız çok muhtemeldir. Yukarıdaki örnekte, oturum açılmış değeri varsaymak için bir saplama kullanırsınız ve ardından uygun değerlerin döndürüldüğünden emin olmak için bir sahte kullanırsınız.

Aptallar

Kodun ne yaptığını umursamadığınızda test kuklaları kullanılır. Belki kodun düzgün çalışması için bir diziyi veya parametre listesini doldurmak için bir kukla kullanıyorsunuzdur. Taslaklar, yazdığınız spesifik test bağlamında muhtemelen önemli olmayan ekstra bilgilerdir.

Oturum açmış bir kullanıcı için, test ettiğiniz işlevin bir parçası belki de bir ad beklemektedir. Mevcut testiniz bu ada ihtiyaç duymasa bile testinizin geçebilmesi için bu adın doldurulduğundan emin olmanız gerekir. Elbette, fonksiyonunuzun sonucunu bu ad olmadan da test etmelisiniz, böylece arıza koşullarını doğru şekilde ele aldığınızdan emin olabilirsiniz.

Fabrikalar

Fabrika, verileri test edebilmemiz için veri modelimize geçerli nesneleri yerleştirmemizi sağlayan bir araçtır. Son örnekte WP_UnitTestCase içindeki kodumuza bir kullanıcı eklediğimizde bir fabrika kullandık.

Burada dikkat edilmesi gereken şeylerden biri kodunuzdaki veri modelini değiştirmektir. Kullanıcınız birdenbire fazladan bir alana ihtiyaç duyarsa, her teste girmeniz ve fabrikayı her kullanışınızda bu ekstra alanı eklediğinizden emin olmanız gerekir.

Maymun Yaması

Bu, çalışma zamanında nitelikleri ve işlevleri dinamik olarak değiştirmek için kullanılan genel bir terimdir. WP_Mock, test için varsayılan WordPress işlevlerinin yerine geçen “maymun yaması”dır. Bu, birim testi yaparken doğrudan WordPress'i aramamıza gerek olmadığı anlamına gelir.

Okumak:  Marvel İzleme Sırası 2023: Türkçe Rehber (En Güncel Sıralama ve Detaylar!)

İddialar

Bir iddia, bir hata olmadığı sürece doğru olacak bir boole değeridir. Bir örnek, bir dosyanın beklenen içeriğe sahip olup olmadığını kontrol etmek için iddiaFileEquals'ı kullanmak olabilir. Dosya beklentileri karşılıyorsa ve geçme testiniz varsa bu doğru olacaktır.

BDD mi yoksa TDD mi?

Şimdi, testlerinize hangi genel sistemle yaklaşacaksınız? Bireysel işlevlerin geçerli olması mı yoksa son kullanıcının gördüğü davranışın geçerli olması mı daha önemli?

TDD

TDD veya Test Odaklı Geliştirme, kodun beklendiği gibi çalıştığını doğrulamak için testler yazdığınız zamandır. Birim testlerinde olduğu gibi, kodun beklentisiyle başlıyorsunuz ve ilerledikçe müşteriye/kullanıcıya doğru çalışıyorsunuz. TDD çıktıları umursamaz, yalnızca testlerin beklendiği gibi çalışmasıyla ilgilenir.

TDD altında yazılan testler yalnızca testi ve bir iddianın ne anlama geldiğini anlayan geliştiriciler tarafından okunabilir.

BDD

BDD veya Davranış Odaklı Gelişim, TDD'nin eksikliklerinden doğdu. Burada son kullanıcının kodun sonucunda ne olmasını beklediğiyle başlarsınız. Hala ilk önce testlerinizi yazarsınız, ancak onları kodunuzun sonucuna odaklarsınız. Beklenen davranış sonuç olduğu sürece BDD, çıktılara nasıl ulaştığınızı umursamaz.

BDD araçlarının büyük bir avantajı Salatalık testi yazmak için kullanılan dilin müşteriler ve geliştiriciler tarafından kolayca okunabilmesidir. Kısa bir girişten sonra müşterilerin Cucumber'ı kullanarak özellik istekleri yazabileceğini anlamak yeterince kolaydır.

Şimdi hangisini kullanmalısınız? Doğru cevap muhtemelen her ikisinden de birazdır. Geliştiricinin yazdığı kodun beklendiği gibi çalışmasını sağlamak için TDD yöntemleri kullanılabilir. BDD, bu kodun çıktısının müşterinin beklediği şekilde olmasını sağlamak için kullanılabilir.

Hepsi bu kadar millet! WordPress için birim testini anlamak artık çok daha kolay. Tüm bu jargonu aklınızda bulundurduğunuzda, elimizdeki tüm araçlarla birlikte TDD ve BDD'yi kullanarak bir eklenti oluşturacağımız bir sonraki yazıya hazır olacaksınız.