Teste dayalı gelişmeyi şu ana kadar anlıyorum ki, başarısız (kırmızı) bir birim testiniz olduğunda sadece verimli kod yazmanıza izin verilir.
Hayır. Testin mesajını değiştirmek için yalnızca mümkün olan en basit kodu yazmanıza izin verilir. Ne tür bir test hakkında hiçbir şey söylemez.
Aslında, bir kabul kriteri için başarısız (kırmızı) bir kabul testi yazarak başlayacaksınız, daha kesin olarak, başarısız olabilecek en basit kabul testini yazıyorsunuz; daha sonra testi yaparsınız, başarısız olduğunu izlersiniz ve doğru nedenle başarısız olduğunu doğrulayın. Daha sonra, bu kabul kriterinin bir işlevselliği için başarısız bir fonksiyonel test yazarsınız, yine başarısız olabilecek, çalıştırabilecek, başarısız olabileceğini izleyen ve doğru nedenden dolayı başarısız olduğunu doğrulayan en basit fonksiyonel testi yazarsınız. Daha sonra başarısız bir ünite testi yazarsın, muhtemelen başarısız olabilecek en basit ünite testidir, başarısız olduğunu izler, doğru nedenden dolayı başarısız olduğunu doğrularsın.
Şimdi , hata mesajını değiştirebilecek en basit üretim kodunu yazıyorsunuz. Testi tekrar çalıştırın, hata mesajının değiştiğini, doğru yöne değiştiğini ve kodun mesajı doğru nedenle değiştirdiğini doğrulayın. (İdeal olarak, hata mesajı şimdiye kadar gitmiş olmalı ve test geçmeli, ancak daha sık sık, testi bir seferde geçmeye çalışmak yerine mesajı değiştirmek için küçük adımlar atmak daha iyidir - nedeni budur neden test çerçeveleri geliştiricileri hata mesajları için bu kadar çaba harcıyorlar?)
Birim testini geçtiğinizde, üretim kodunuzu testlerinizin koruması altında yeniden değerlendirirsiniz. (Şu anda, kabul testinin ve işlevsel testin hala başarısız olduğunu, ancak sorun değil, çünkü yalnızca ünite testlerinin kapsadığı ayrı üniteleri yeniden değerlendiriyorsunuz.)
Şimdi bir sonraki ünite testini yaratır ve fonksiyonel test de geçene kadar yukarıdakileri tekrarlar. İşlevsel testin koruması altında, artık birden fazla birimde yeniden düzenleme yapabilirsiniz.
Bu orta döngü artık kabul testi geçene kadar tekrar eder; bu noktada şimdi tüm sistemde yeniden yapılanma yapabilirsiniz.
Şimdi, bir sonraki kabul kriterini seçersiniz ve dış döngü yeniden başlar.
TDD'nin "keşfi" Kent Beck ("mucit" terimini beğenmiyor, insanların bunu başından beri yaptığını söylüyor, sadece bir isim verdi ve bunun hakkında bir kitap yazdı) fotoğrafçılıktan bir benzetme kullanıyor ve buna "yakınlaştırma ve uzaklaştırma" denir.
Not: Her zaman üç test seviyesine ihtiyacınız yoktur. Belki, bazen daha fazlasına ihtiyacınız vardır. Daha sık, daha azına ihtiyacınız var. Eğer işlevsellik parçalarınız küçükse ve fonksiyonel testleriniz hızlıysa, o zaman olmadan (veya daha az birim testiyle) yapabilirsiniz. Genellikle, yalnızca kabul testlerine ve ünite testlerine ihtiyacınız vardır. Ya da, kabul kriterleri böylece kabul testleri o ince taneli olan olan fonksiyonel testler.
Kent Beck, hızlı, küçük ve odaklanmış bir fonksiyonel testi varsa, önce birim testlerini yazacağını, birim testlerinin kodu sürmesine izin vereceğini ve sonra da kodunu kapsayan birim testlerini tekrar sileceğini (bazılarını) sileceğini söylüyor. hızlı fonksiyonel test tarafından kapsanmaktadır. Unutmayın: Test kodu aynı zamanda bakımı ve yeniden bakımı yapılması gereken koddur, ne kadar az olursa, o kadar iyi!
Ancak, sınamaya dayalı yaklaşımın diğer sınama biçimlerine de uygulanıp uygulanamayacağını merak ediyorum.
TDD'yi gerçekten testlere uygulamıyorsunuz. Tüm geliştirme sürecinize uygularsınız. Test Destekli Gelişimin "yönlendirilen" kısmı bu anlama geliyor: tüm gelişiminiz testler tarafından yönlendiriliyor. Testler sadece yazdığınız kodu değil aynı zamanda hangi kodu yazacağınızı, sonra hangi kodu yazacağınızı da belirler. Tasarımınızı yönlendirirler. İşin bitince sana söylerler. Daha sonra ne üzerinde çalışacağınızı söylerler. Size kodunuzdaki tasarım kusurlarını anlatıyorlar (testlerin yazılması zor olduğunda).
Keith Braithwaite dediği bir egzersiz yarattı bunu yürekten olursa TDD Farklı . Bu, sıkı bir şekilde izlemeniz gereken ve sizi TDD'yi daha titizlikle uygulamak için yönlendirmek için tasarlanan bir dizi kuraldan ( Bob Amca Martin'in TDD'nin Üç Kuralları'na dayanır , ancak daha katıdır) oluşur. Çift programlamasında en iyi şekilde çalışır (çiftiniz kuralları ihlal etmediğinizden emin olmanızı sağlar) ve bir eğitmen.
Kurallar:
- Tam olarak bir yeni test yazın, çözüm yönünde işaret edebilecek en küçük testi yazın.
- Başarısız bakın; derleme hataları, başarısızlıklar olarak sayılır.
- Test yönteminde bulabileceğiniz en az uygulama kodunu yazarak testi (1) 'den başarılı yapın .
- Yinelemeyi gidermek için Refactor ve tasarımın iyileştirilmesi için gerektiği şekilde. Bu hareketleri kullanma konusunda kesin olun:
- yeni bir yöntem istiyorsan - yeniden yapılanma zamanına kadar bekle, sonra… bunlardan birini yaparak yeni (test dışı) yöntemler yarat:
- tercih edilen: Test sınıfında yeni bir yöntem oluşturmak için (3) 'e göre oluşturulan uygulama kodunda Ayıklama Yöntemi yapın veya
- Yapmanız gerekiyorsa: Uygulama kodunu (3) uyarınca mevcut bir uygulama yöntemine taşımak
- yeni bir sınıf istiyorsan - yeniden toparlanma zamanına kadar bekle, sonra… bir Move Yöntemi için bir hedef sağlamak ve başka bir sebep olmadan test dışı sınıflar oluşturmak
- Hammadde Yöntemi'ni kullanarak, uygulama sınıflarını yöntemlerle doldurma
Bu kurallar TDD'yi uygulamak içindir. Bunlar aslında üretimde TDD yapmak anlamına gelmezler (hiçbir şey denemenizi engellemese de). Sinir bozucu hissedebilirler, çünkü bazen gerçek bir ilerleme kaydetmeden binlerce ufacık küçük adım atarsınız.
