WordPress'te Birim Testine Giriş – QUnit ile JavaScript

Hâlâ WordPress'te birim testiyle ilgileniyor musunuz? Bu iyi, çünkü bugün PHP'den JavaScript'e ve dolayısıyla ön uca geçeceğiz! Oldukça havalı, ha? ? Bu yazıda size JavaScript kodunun birim testi için bazı çerçeveler sunacağım ve adım adım bir örnek göreceğiz. Artık (neredeyse) uzman bir birim testçisi olduğunuza göre, sevdiğim birkaç YouTube videosunu paylaşacağım ve bu size konuyla ilgili daha fazla bilgi edinmenizi sağlayacak.

Ancak JavaScript dünyasına dalmadan önce…

PHPUnit sorunumuzun çözümü

Bir önceki yazıda sana biraz ödev vermiştim, hatırladın mı? İşte senden yapmanı istediğim şey:

neliovat_get_vat işlevini, para miktarları 15,20 , 1.000 veya 3€ gibi dizeler olarak ifade edilecek şekilde yeniden yazın (isteğe bağlı binlik ayırıcının . , ondalık ayırıcının , olduğu yerde, bir para birimi simgesi olabilir ve boşluk olmayabilir) testi geçer.

Sunduğum orijinal işlev şuydu:

ve başarısız olan test şuydu:

Peki, bunu nasıl çözeceğiz? Fikir oldukça basit; kurtulmanız gereken (binlik ayırıcı veya para birimi gibi) bazı "fazladan" karakterlere sahip bir dizeniz var ve ondalık ayırıcıyı virgülden noktaya değiştiriyorsunuz. Bunu yaparsanız, sayı PHP tarafından bir kayan sayı olarak anlaşılabilir ve dolayısıyla KDV'si hesaplanabilir. Ortaya çıkan işlev şöyle görünür:

ve testi tekrar çalıştırdıktan sonra aldığınız sonuçlar:

JavaScript Test Çerçeveleri

PHP'yi test etmek istiyorsanız, en bariz çözüm PHPUnit'tir—birim testi için “gerçek” bir alternatif yoktur. Ancak JavaScript hakkında konuşursak, gerçek tamamen farklıdır; seçebileceğiniz birçok seçenek vardır. Stateofjs'de bazı JavaScript test çerçevelerinin ayrıntılı bir karşılaştırması var ve dostum, bu çok büyük!

moka

Mocha, hem Node.js'de hem de tarayıcınızda çalışabilen, basit, genişletilebilir ve hızlı bir test paketi olarak oluşturulmuş, zengin özelliklere sahip bir JavaScript test çerçevesidir. Birim ve entegrasyon testi için kullanılır ve ayrıca Davranış Odaklı Geliştirme (BDD) için harika bir adaydır.

Yasemin

Bir başka modaya uygun çerçeve ise Jasmine. Web sitelerinde belirtildiği gibi, JavaScript kodunu test etmek için davranışa dayalı bir geliştirme çerçevesidir. Jasmine bir DOM gerektirmez, bağımlılığı yoktur ve temiz ve net bir sözdizimine sahiptir. Belgeleri de oldukça iyidir, bu nedenle nasıl kullanılacağını hızlı bir şekilde öğrenebilirsiniz.

Hangisinin daha iyi olduğunu merak ediyorsanız, onları (ve diğerlerini) karşılaştıran çok sayıda blog yazısı var. Yine de benim fikrimi istiyorsan hepsini denemeli ve seni en mutlu edene bağlı kalmalısın. Ancak, QUnit'e de bir göz atmak isteyebilirsiniz.

QBirim

QUnit, bugün bahsetmek istediğim son JavaScript test çerçevesidir. Amacı jQuery'yi test etmekti (tanıdınız değil mi?) ve bir süredir bizimle. Anlayabildiğim kadarıyla, QUnit biraz ivme kaybetmiş gibi görünüyor, ancak QUnit, JavaScript bileşenlerini test etmek için WordPress'te kullanılan çerçeve olduğundan, bunun hakkında konuşmaya değer.

İlk QUnit Testimizi Ayarlama

Çok nelio_get_vat fonksiyonumuzun functions.js adlı bir JavaScript dosyasına yazıldığını varsayalım:

Gördüğünüz gibi, süslü bir yanı yok—bu PHP'de gördüğümüz, ancak JavaScript'te yazılmış olan işlevdir. Bu nedenle, bu işlev (muhtemelen) PHP karşılığı gibi davranacaktır – biçimi ne olursa olsun herhangi bir paranın %21 KDV'sini hesaplayacaktır. İşlev hem sayıları hem de dizgileri kabul eder ve dizgiler de… işlevimize zaten aşinasınız, değil mi?

Bu işlevin geçmesini istediğimiz testler, örneğin, tests.js adlı bir dosyada aşağıdaki gibi yazılabilir:

Belirli testleri biraz değiştirdim, ancak neler olup bittiğini anlamakta sorun yaşamadığınıza eminim. İşlevimizin bu testleri geçip geçemeyeceğini kontrol etmek için, tüm gereksinimleri içeren küçük bir HTML belgesi oluşturmamız gerekiyor: QUnit kitaplığı, test etmek istediğimiz JavaScript işlevi ve testlerin kendisi:

Bu belgeyi şimdi web tarayıcımızda açarsak, aşağıdakileri alırız:

bu, tüm testlerimizin tam bir başarı olduğu anlamına gelir!

Daha İyi Bir Programcı ve Testçi Olmak İçin Birkaç İpuçları ve Püf Noktaları

Gördüğünüz gibi, birim testlerinin arkasında hiçbir sihir yok – elbette, henüz tartışmadığımız pek çok şey var (örneğin, zaten var olan verilerle bir ortamın nasıl kurulacağı gibi), ancak her şey kullanmakla ilgili. test çerçevesi ve işlevleri doğru şekilde. Gerçek şu ki, test ettiğiniz dil gerçekten önemli değil – önemli olan teste bir kavram olarak inanmak ve bunu yaparken mümkün olduğunca verimli olmaya çalışmaktır.

En zor kısım, her zaman olduğu gibi, başlamak ve inisiyatife ayak uydurmak. “Doğru bileşeni test ediyor muyum?”, “Önemli bir şeyi mi unutuyorum?”, “Bu testler gerçekten faydalı mı?”, “Bu testi atlasam kimsenin umrunda olur mu?” gibi sorular her zaman kolay değildir. cevaplamak ve cevaplar cesaret kırıcı olabilir. Ama onlara kendin soruyorsan, en azından umursadığın açık.

Çoğuna cevap verebilmek için aşağıdaki videoları izlemenizi tavsiye ederim. İkisini de sevdim ve ara sıra tekrar izlerim.

Bu ilk videoda Roy Oserove, JavaScript kodunu test ederken iyi uygulamalardan ve korkunç hatalardan bahsediyor (ancak daha önce de söylediğim gibi, fikirleri tüm diller ve test çerçeveleri için geçerlidir). Gerçekten bir saatinizi ayırmanızı ve videoyu izlemenizi tavsiye ediyorum – test becerilerinizi kolay ve etkili bir şekilde nasıl geliştireceğinizi öğretiyor.

Bence konuşmasının en ilginç kısımları:

• İyi bir birim testinin üç temel özelliği vardır (videoda izleyin)
  1. GÜVENİLİR . Test size her şeyin yolunda olduğunu söylerse ve buna güvenmiyorsanız, gerçekten olduğundan emin olmak için kodunuzu yeniden kontrol etmek isteyeceksiniz. Veya size bir şeylerin doğru olmadığını söylerse ve siz buna inanmıyorsanız, kendinize “hey, testler bazen başarısız olur; Eminim her şey yolundadır”. Görmek? Testinizin sonuçlarına güvenmiyorsanız, neden ilk etapta bunları oluşturmak için zahmete giresiniz?
  2. BAKIM YAPILABİLİR . Testler sonunda değişecektir çünkü test edilen kodunuz da muhtemelen değişecektir, bu nedenle bunların temiz ve anlaşılır olduğundan emin olun. Eşsiz bir testte çok fazla bilgiyi birbirine karıştırmayın, gelecekteki ihtiyaçlarınıza kolayca uyarlanabilmeleri için onları temiz ve kısa tutun.
  3. OKUNABİLİR . Bir test başarısız olursa, programcı nedenini bilmek isteyecektir. Başka bir deyişle, muhtemelen teste bakmaları, okumaları ve neyi test etmesi gerektiğini anlamaları gerekecek (doğru şekilde adlandırılmışsa, kaynak kodunu bile atlayabilirler). Testiniz okunamıyorsa, siz ve gelecekteki programcılar kodunuzu korumakta sorun yaşayacaksınız.
• Testler basit olmalıdır (videoda izleyin). Bir teste ne kadar çok kod eklerseniz, testin kendisinde hatalar olması o kadar olasıdır. Ve bu biraz garip! Test kodunuzun hata içermesini istemezsiniz. Bunu “garanti etmenin” en kolay yolu basit testler yazmaktır. Bu nedenle, döngüler, if/else ifadeleri vb. olmadan kısa, basit testler yazmaya çalışın.
• Anlamlı isimler kullanın (videoda izleyin). Bu muhtemelen videonun en aydınlatıcı kısmı. İnsanların bir testin ne yaptığını gerçekten anlamasını istiyorsanız, onu doğru bir şekilde adlandırın. Bunu yapmak için, aşağıdaki üç yönün mükemmel bir şekilde belirtildiğinden emin olun:
  1. İş Birimi : NE test ediyoruz. Bu bir sınıf, fonksiyon, modül olabilir… her neyse, ama açıkça belirtildiğinden emin olun.
  2. Senaryo : Testi NE ZAMAN ve NASIL yapıyoruz, bağlam nedir. Ne olursa olsun tamamen aynı davranan işlevler vardır, diğerleri özniteliklerinin türlerine, diğerleri veritabanı durumuna bağlıdır. Örneğin, var olmayan bir gönderiyi kaydetmek, zaten var olan bir gönderiyi kaydetmekten farklı davranır, bu nedenle senaryo şudur: yeni bir örneği mi kaydediyoruz yoksa zaten var olan bir örneğin üzerine mi yazıyoruz?
  3. Beklenen Davranış : Testimizin sonucunda NE olmalı (veya olmamalı)? Buradaki en önemli kısım, SHOULD ve SHOULDN'T fiillerinin kullanılması gerektiğini belirtmektir. Örneğin, aşağıdaki test çok açıktır: “ wp_post_save (iş birimi) işlevi göz önüne alındığında, zaten var olan bir gönderiyi kaydettiğimizde (senaryo), gönderinin kimliği kaydetmeden öncekiyle aynı olmalıdır (beklenen davranış) ”. Öte yandan, beklenen davranış "…, posta kimliği kaydetmeden öncekiyle aynı" şeklindeyse, bir sorun bildirip belirtmediğimiz açık değildir (posta kimliği aynıdır ve olmamalı) ya da zaten ne beklediğimizi belirtiyorsak.

İkinci video yeni başlayanlar için çok faydalı. Kodumu test etmeye başladığımda en çok zorlandığım şeylerden birinin test edilememesi olduğunu hatırlıyorum – kodum o kadar karmaşık değildi, ama nasıl test edeceğimi bilmiyordum!

İşte o zaman Rebecca bana ışığı gösterdi! 4:43'te Rebecca küçük bir JavaScript uygulaması gösteriyor ve kaynak kodunu gösteriyor—bu çok zarif değil, ama dağınık da değil. Yoksa öyle mi? Bu eskiden yazdığım türden bir koddu (ve itiraf etmeliyim ki bazen hala yazıyorum), ancak bu kod hiç test edilemez! Farklı işlevler iç içe geçmiş durumda, UI ile uygulama durumu arasında, sunucu iletişimi ile kurulum arasında net bir ayrım yok, birçok lambda işlevi var…

Birkaç dakika sonra, konuşmacı size ışığı gösterir ve testinizin test edilebilir ve sonuç olarak okunabilir ve sürdürülebilir olması için testinizi nasıl yazacağınızı söyler:

• Örnekler oluşturmak için yapıcıları kullanın
• Destek yapılandırılabilirliği
• Yöntemleri basit tutun
• Sorumlulukları birbirine karıştırmayın

Her bir yönergeyle ilgili düşüncelerini özetlemeye çalışabilirim, ancak gerçekten, gerçekten, onun bunları açıklamasını izlemenizi tavsiye ederim. Bunu yaparsanız, bunları kendi işinizde uygulamanın ne kadar harika olduğunu göreceksiniz.

Özetle

JavaScript kodunu test etmek, PHP veya başka bir dili test etmekten farklı değildir. Önemli olan, (ilk) kodu test etmeye başlama ve (ikinci) becerilerinizi geliştirme isteğinizdir, böylece kodunuzun kolayca test edilebilmesi ve sonuç olarak, kendi başına daha iyi kod haline gelebilir. Testlerin kısa ve net olması gerektiği gibi test edilen bileşenleriniz de öyle olmalıdır. Yukarıdaki videolarda açıklanan yönergeleri uygularsanız daha iyi bir testçi ve programcı olursunuz; Bunu garanti ederim!

Gelecek hafta, hem PHP'yi hem de JavaScript'i test edeceğimiz WordPress'te tam bir örnek göreceğiz. Özellikle, küçük bir AJAX geri araması oluşturacağız ve hem ön ucu hem de arka ucu nasıl test edeceğimizi göreceğiz. Yakında görüşürüz! ??

Öne Çıkan Görsel: etringita.