Drupal'da Test Odaklı Gelişme (TDD) nasıl yapılır?

• Drupal'da TDD kullanılan araçlar nelerdir (PHP modülleri, Drupal modülleri, vb.)?
• Taahhüt / test / dağıtım iş akışınız neye benziyor? Bu iş akışını yönetmek için Phing, PHPUnderControl, Hudson kullanıyor musunuz?
• Ünite testi hangi şekilde kodunuzu daha güvenilir kılar?
• Ayrı, pahalı, bağımsız bir birim test sunucusuna mı ihtiyacınız var, yoksa bunu bir dizüstü bilgisayardan yapabilir misiniz?

Robert'ın burada SimpleTest ile Drupal'de birim testi hakkında mükemmel bir teknik yazı yazdığını biliyorum ; İş akışı ve konfigürasyon bölümünü ele almakla daha çok ilgileniyorum. Şu anda bir geliştirme makinesi, evreleme ve üretim sunucum var. Hem üretim hem de sahne siteleri 300 MB RAM / 300 MHz CPU Dreamhost VPS ile çalışır.

Yakut dünyasında, TDD çerçeveye yerleştirilmiş aletlerle kolaylaştırılmıştır. Factory Girl, Mocha, rSpec ve diğerleri, geliştiricilerin ihtiyaç duydukları test durumlarını ele alan kolay ve dinamik bir şekilde test oluşturmalarına izin veriyor.

Ben de Drupal'daki TDD araçlarının bulunmamasından dolayı hüsrana uğradım. Onlarla en büyük sorunum, tek bir test yapmak için geçen zamanın miktarı. Gelişim döngüleri, her bir yinelemede 60-90 saniye süren bireysel testlerle yavaşlatılamaz. Testleri hiç yazmak için uğraşmazsanız, tam test paketleri birden fazla saatlik zaman diliminde çalışacaktır.

Bir test yapıldığında her seferinde tam bir db kopyalama yapılması gerektiğinden şüpheleniyorum, ancak yakın bir zamanda söyleyebileceğimden, özellikle de bunu yapmak için DrupalWebTestCase kullanmanız gerekiyorsa, bunun değişmesi muhtemel değildir.

Manuel olarak önyükleme yapan Phactory ve phpunit kullanarak bir çözümü hackledim . Belli ki bazı meselelerle yüzleşip bitmedi, ama oraya varıyor.

Neyse ki çalışmalarımın çoğu arka uç katmanında, bu yüzden DRUPAL_BOOTSTRAP_DATABASE seviyesinde kalabilirim. Ama tam yığına ihtiyacım olacağı daha fazla durum için koşuyorum.

Sonunda, Drupal'daki TDD iyi bir şekilde desteklenmiyor, bu yüzden drupal test çerçevesi dışında çalışmasını sağlamak veya düşük performansa katlanmak için kendiniz yazabilirsiniz.

- GÜNCELLEME -

Phactory ile başarılı bir Drupal entegrasyonu başarıyla kurdum ve şimdi Drupal Web Test Case yerine phpunit ile testlerimi yapıyorum. Bu yüzden mümkün.

İnşallah onu bırakabileceğim bir noktaya geleceğim ve Phactory belgesine dahil olabilirim.

- GÜNCELLEME 2 -

Phactory'yi nasıl kurduğum konusunda doktor https://github.com/trimbletodd/phactory adresindedir .

Mark'ın blogu çevrimdışı olduğu için ekibinin uyguladığı bazı araçlardan bahsedeceğim:

Fonksiyonel test: Selenyum
Ünite testi: En basit
Yapı sunucusu: Jenkins
Performans kıyaslama: XDebug + Cachegrind

Bu soruyu sorduğumdan beri iki yıl içinde TDD sahnesine popülerlik kazandıran bazı ek araçlar gördüm. Bugünlerde Test Odaklı Gelişimden bahsettiğinizde (elbette Drupal bağlamında) aynı madalyonun iki yüzü vardır - ön uç testi ve arka uç testi.

Bu konuyu temsil eden en son Drupalcon Portland 2013'ten öne çıkan iki sunum:

Sayılarla Geliştirme, arka uç testi.
Jasmine ve PhantomJS ile otomatik test , ön uç testi.

İlk sunum, ünite veya fonksiyonel testlerle (kesinlikle konuşmuyor) ilgili değil, kod kalitesini ölçmek için araçlar hakkında daha fazla. Yine de, bunun konu ile ilgili olduğunu düşünüyorum.

Farkında olduğum tek şey, katkıda bulunan modüller için, sıradaki taahhüt ve yamaların otomatik olarak test edilmesini sağlayabileceğinizdir , bkz. Http://drupal.org/node/689990 . Özellikle bağımlılıklarınız varsa hala biraz kararsız.

Pek çok proje muhtemelen daha çok hataya dayalı gelişim çizgisinde bir şeyler yapıyor; bu, temel olarak ilk önce bir hata bulunduğunda bir test yazmaya ve daha sonra düzeltmeye dayanıyor. Hiç değilse ;)

Benim kişisel tecrübelerime göre TDD, Drupal'da oldukça zor, çünkü çoğu kez sayfa testlerini ve formları gönderdiğiniz En Basit ama entegrasyon testleriyle (sadece) birim testleri yazmıyorsunuz. Bu yüzden önceden iyi testler yazmak oldukça zor olabilir. Ama belki de sadece bunu yapmaya alışkın değilim :)