WordPress 7.2 için PHPUnit test temizliği çağrısı açıldı

🇬🇧 English: Read this in English →

Otuz yıldır yazılım projelerinin nasıl yaşlandığını izliyorum ve bir kalıp hep aynı çıkıyor: dürüst hikâyeyi sana test paketi anlatır. Yol haritaları yalan söyler. Ekran görüntüleri yalan söyler. Ama sessiz sessiz durum sızdıran, hiçbir şey iddia etmeyen ya da her koşuşta canlı internete telefon eden bir test paketi — kod tabanının içeride kaç yaşında hissettiğini sana kelimesi kelimesine söyler.

WordPress artık bu sorunu gün ışığında tartışacak kadar olgun. Lance Willett’in bu hafta 7.2 sürümü için açtığı PHPUnit test temizliği çağrısı, sürüm notunun kapak manşeti olacak bir özellik değil. Bir bakım işi. Ama her gelecek sürümün ne kadar hızlı çıkacağını ve pull request’in yeşil onayına ne kadar güvenebileceğini belirleyen türden bir bakım işi.

Hâlâ zaman zaman özlediğim Flash ve Director yıllarında test yoktu. Bir Director projesini yorulana kadar tıklardın; sen projeden önce yorulursan hatayı müşteri bulurdu. Test paketi medeniyettir. Medeniyetin de bakımı gerekir.

Gerçekten yeni olan ne

Lance Willett 8 Eylül’de Make/Core üzerinde Join the PHPUnit Test Cleanup for 7.2 başlıklı yazıyı yayımladı. Ton doğrudan: WordPress her commit’te yaklaşık 31.000 PHPUnit testi koşuyor, bunların bir kısmı komşu testlere durum sızdırıyor, bir kısmı hiçbir iddiada bulunmuyor, birkaçı da canlı ağ çağrılarına bağımlı. Build/Test Tools bileşeninin 7.2 için açık hedefi artık şu: “wordpress-develop ve bağlı depolarda build süresini ve yükü azaltmak.”

Yazı işi sekiz ayrı şeride bölüyor; her şeridi bir katkıcı bağımsız üstlenebiliyor. Rastgele dizin sırasıyla test izolasyonu Trac #65893’te takip ediliyor. İddia denetimleri — 26 dosyada 101 @doesNotPerformAssertions notu, 98’i REST controller testlerinde yoğunlaşmış — #40538’de. Gevşek assertEquals() çağrılarını sıkı assertSame() ile değiştirmek #64895; 124 dosyada 501 aday duruyor. Aşırı büyümüş test sınıflarını her birim için tek sınıfa bölmek #65208. Harici HTTP çağrıları PR #13407’ye bağlı ve #63914’te izleniyor. Trac #66074, tüm paketin çalışma süresinin yarısını üstlenen yirmi iki test sınıfını hedefliyor. #65819 küçük temizlik kovası. #65889 ise yalnızca CSS ya da JavaScript değiştiren pull request’lerde PHPUnit matrisini tamamen atlıyor.

Yazı, kendi başına dikkat çekmesi gereken bir altyapı ayrıntısını da doğruluyor: trunk’a yapılan push’lar artık süre ölçümlerini CodeVitals‘e yayınlıyor. Yavaş bir test artık sezgi değil, veri noktası. 9 Eylül Dev Chat gündemi temizliği toplantıya taşıyor, Core Build/Test Tools ekibi de #core-build-test-tools kanalında iki haftada bir salı 15:00 UTC’de buluşuyor; bir sonraki tarih 22 Eylül.

Aynı günden iki bitişik sinyali de not etmek gerek. Aynı günkü Performance Chat özetinde sorgu önbelleği çalışması PR #12220 ve script/style birleştirmesinin kaldırılması PR #13084 hâlâ performans ekibinin gündeminin en üstünde duruyor. WordPress’in PHPUnit el kitabı ise rastgele sıralama, grup filtreleri ve Docker tabanlı koşumun zaten desteklendiğini sessizce belgeliyor — hammadde orada, istenen şey onun etrafındaki disiplin.

Neden WordPress ve WooCommerce tarafı için önemli

Bu, çatının hikâyesi. Duvar kâğıdının değil. Kimse sürüm sayfasında “daha hızlı bir test paketi” pazarlamaz. Ama kurduğun her sürüm, güvendiğin her eklenti yaması, bu paketin nöbetinden geçti. Duvar saati süresinin yarısı yirmi iki sınıfta harcanıyorsa, her merge-conflict rebase’i, her yama backport’u, her güvenlik sürümü sana orantısız CPU ve orantısız beklemeye mâl oluyor demektir. Bazı testler hiçbir iddiada bulunmuyorsa, uzun süredir parasını ödediğin yeşil onay bir yalan demektir.

Ajanslar ve eklenti geliştiricileri için pratik okuma daha da doğrudan. WordPress çekirdeği açık açık şunu diyor: durum sızdıran testler, sahte olmayan HTTP çağrıları ve gevşek eşitlik iddiaları teknik borçtur. Kendi eklentinin PHPUnit paketi neredeyse kesinlikle aynı üç günahtan besleniyor. 7.2 sprint’i sana hareket eden bir referans veriyor — aynı Trac biletleri, aynı yakınsamalar, aynı el kitabı — kendi test stil rehberini sıfırdan icat etmene gerek kalmadan.

WooCommerce’in Store API’si ve Cart/Checkout blokları WordPress’in REST controller test kalıplarına yaslanıyor; REST controller testlerindeki iddia temizliği er ya da geç Woo’nun kendi test hijyenine de yansıyacak. 10.9’da deneysel olarak çıkan dual API çalışması bu mirası daha az değil, daha görünür kılıyor.

WordPress insanlarının kaçırmaması gereken bir yönetişim noktası da var. Kendi test hijyenini herkesin gözü önünde — biletler, sayılar ve bir metrik panosuyla — denetime açan bir proje, büyüyecek yeri olan bir projedir. Müşterilere “neden yeni bir barındırmalı içerik yönetim sistemi peşine düşmek yerine WordPress’te kalmalısın” sorusuna verdiğim cevap tam da bu olgunluk hikâyesidir. İşte tam bu şekilde görünüyor.

Ben olsam ne yaparım (ya da yapmam)

Çekirdeğe katkı veriyorsan ya da vermek istiyorsan, bu son yılların en sıcak giriş rampalarından biri. Şeritler küçük, biletler isimli, inceleme yolu açık. Trac #66074’ten bir sınıf seç, PHPUnit el kitabının belgelediği Docker akışıyla yerelde profilini çıkar ve bir saniye tıraşlayan bir pull request aç. Bu gerçek bir katkıdır; “triyaja yardım ettim” cümlesinin özgeçmişte hiç veremediği biçimde okunabilirdir.

Eklenti bakıyorsan modeli ödünç al. Kendi paketinde assertEquals‘i grep’le, her sonucu assertSame adayı say. @doesNotPerformAssertions‘ı grep’le ve her birini denetle — ya gerçek bir iddia ekle ya da testi sil. Paketi rastgele sırayla çalıştır ve neyin devrildiğine bak; eklenti paketlerinde durum sızıntısı utandırıcı ölçüde yaygın. Ve her harici HTTP çağrısını bir mock ile koru, çünkü canlı internete çıkan bir paket, CI koşucusunun DNS çözemediği gün patlayan bir pakettir.

Bir WordPress ajansı yönetiyorsan, kendi iç şablonun için de bu denetime bir çeyrek ayır. Projeden projeye taşıdığın starter kit büyük olasılıkla aynı üç günahı taşıyor ve retainer müşterilerdeki sabit fiyatlı hata bütçesi tam da orada eriyor.

Bunu projenin yavaş olduğunun belirtisi gibi okumazdım. Tam tersi. Kendi yavaş sınıflarını, eksik iddialarını, ağ bağımlılığını isim isim adlandırıp Make/Core’da metrik panosuyla yayımlayan bir ekip, kendisiyle dürüst olmayı seçmiş bir ekiptir. Bu, herhangi bir sürüm notundan daha değerlidir.

Bir sonraki Build/Test Tools toplantısı 22 Eylül’de #core-build-test-tools‘da. WordPress’i ayakta tutan tesisatta çalışmayı hiç merak ettiysen, oda o oda.