Robert'ın Drupal SimpleTest ile birim testi hakkında mükemmel bir teknik yazı burada yazdığını biliyorum; Ben daha çok iş akışı ve yapılandırma bölümünü kapsayan ilgileniyorum. geliştirme makinesi, evreleme ve üretim sunucusu: Hem üretim hem de sahne siteleri 300MB RAM/300MHz CPU Dreamhost VPS ile çalışır.
Ruby dünyasında TDD, çerçeveye yerleştirilmiş araçlarla kolaylaştırılmıştır. Factory Girl, Mocha, rSpec ve diğerleri, geliştiricilerin ihtiyaç duyulan test senaryolarını ele alan kolay ve dinamik testler oluşturmalarına izin verir.
Drupal'daki TDD araçlarının eksikliğinden de sinirli oldum. Onlarla ilgili en büyük sorunum, tek bir test yapmak için gereken süredir. Geliştirme döngüleri, her yinelemenin 60-90 saniyesini alan bireysel testlerle yavaşlatılamaz. Testleri yazmakla uğraşmazsanız, tam test paketleri birden fazla saatlik zaman diliminde çalışır.
Ben bir test her çalıştırıldığında tam bir db kopyalama ile ilgili olduğundan şüpheleniyorum, ama bu yakın gelecekte özellikle ne yapmak için DrupalWebTestCase kullanmanız gerekiyorsa söyleyebileceğimden değişmesi muhtemel değildir.
Phactory ve phpunit kullanarak bootstraps Drupal elle manuel olarak bir çözüm kesmek. Açıkçası bazı sorunların içine çalışan ve bitirmedi, ama oraya geliyor.
Neyse ki işimin çoğu arka uç katmanında, bu yüzden DRUPAL_BOOTSTRAP_DATABASE düzeyinde kalabilirim. Ama tam desteğe ihtiyacım olacak daha fazla durumla karşılaşıyorum.
Sonunda, Drupal içindeki TDD iyi desteklenmemektedir, bu nedenle drupal test çerçevesinin dışında çalışmasını sağlamak için kendiniz yazabilir veya zayıf performans.
-- GÜNCELLEME --
Başarıyla tam bir Drupal Phactory ile entegrasyon kurduk ve şimdi testlerimi Drupal Web Test Case yerine phpunit üzerinden çalıştırıyorum.).
Umarım serbest bırakabileceğim bir noktaya geleceğim ve Phactory dokümanı ile birleştirilebilir.
- GÜNCELLEME 2 -
Phactory'yi nasıl ayarladığım hakkında bilgi https://github.com/trimbletodd/phactory .
Mark'ın blogu çevrimdışı olduğundan, ekibinin uyguladığı bazı araçlardan bahsedeceğim:
Fonksiyonel test: Selenyum
Birim testi: En basit
Sunucu oluştur: Jenkins
Performans karşılaştırması: XDebug + Cachegrind
Bu soruyu sorduğumdan bu yana geçen iki yıl içinde TDD sahnesine popülerlik kazandıracak bazı ek araçlar gördüm. Günümüzde Test Odaklı Geliştirme'den bahsettiğinizde (= Drupal bağlamında) aynı madalyonun iki yüzü vardır - ön uç testi ve arka uç testi.
İşte bu konuyu temsil eden en son Drupalcon Portland 2013'ten öne çıkan iki sunum:
İlk sunum birim veya fonksiyonel testle (kesinlikle konuşursak) ilgili değildir, daha çok kod kalitesini ölçmek için araçlar hakkındadır. Yine de, konuyla biraz ilgili olduğunu hissediyorum.
Katıldığım tek şey, katkıda bulunan modüller için, sorun kuyruğunda taahhütlerin ve yamalarının otomatik testini etkinleştirebilmenizdir, bkz. http://drupal.org/node/68999 . Özellikle bağımlılıklarınız varsa hala biraz kararsız.
Çoğu proje muhtemelen hata güdümlü geliştirme çizgileri boyunca bir şeyler yapıyor, bu da temel olarak bir hata bulunduğunda önce bir test yazmaya ve sonra düzeltmeye geliyor. Hiç değilse ;)
Kişisel deneyimime göre TDD, Drupal'da oldukça zor, çünkü sayfaları görüntülediğiniz ve formları gönderdiğiniz en basit ancak entegrasyon testleriyle genellikle (yalnızca) birim testleri yazmıyorsunuz. Bu yüzden önceden iyi testler yazmak oldukça zor olabilir. Ama belki de bunu yapmaya alışık değilim :)