Tanımları okurken, TDD testlerinde fonksiyon yazılmadan önce ve Birim Testinde, daha sonra yapıldığını anlıyorum.
Bu ana fark mıdır yoksa iki terim de bu şekilde karşılaştırılamaz. Belki, Birim Testi TDD'nin entegre bir parçasıdır.
Birim Testi, ne test edeceğiniz anlamına gelir, TDD - ne zaman test ediyorsun.
İkisi dikeydir.
Birim Testi, bireysel davranış birimlerini test etmek anlamına gelir. Tek bir davranış birimi, ayrı ayrı ayrı ayrı test edilebilen mümkün olan en küçük davranış birimidir. (Bu iki tanımın dairesel olduğunu biliyorum, ancak pratikte oldukça iyi çalışıyor gibi görünüyorlar.)
Kodunuzu yazmadan önce, kodunuzu yazdıktan sonra veya kodunuzu yazarken birim testleri yazabilirsiniz.
TDD (yine açık bir şekilde) testlerinizin gelişiminizi (ve tasarımınızı) yönlendirmesine izin vermek anlamına gelir. Bunu birim testleri, fonksiyonel testler ve kabul testleri ile yapabilirsiniz. Genellikle üçünü de kullanırsınız.
TDD'nin en önemli kısmı orta D . Testlere izin verirsin sür sen. Testler, ne yapacağınızı, bir sonraki adımda ne yapacağınızı, işiniz bittiğinde size söyler. API'nın ne olacağını, tasarımın ne olduğunu size söylerler. (Bu önemlidir: TDD ilk önce test yazma ile ilgili değildir. Önce test yazan ancak TDD uygulamayan birçok proje vardır. İlk önce testlerin yazılması, testlerin geliştirme sürecine izin vermesi için bir ön koşuldur.)
Test odaklı geliştirme yapmadan birim testi yapabilirsiniz. Ancak, birim testleri kullanmadan test odaklı geliştirme yapamazsınız.
Geleneksel birim testi yaptığınızda, test sonra kodunuzu yazdınız.
Test odaklı geliştirme yaklaşım birim testi yazmak önce kod yazma.
Basit Birim Testine kıyasla TDD'nin (IMHO) en ilginç avantajları:
TDD ve Birim Testi, sıklıkla yanlış kullanılan iki spesifik terimdir.
TDD başarısız olacak bir test yazıyor, daha sonra çalışmasını sağlamak için gereken minimum kod miktarını yazıyor ve daha sonra temizlemesi için kodu yeniden düzenliyor. Bu işlem, kod için bilinen her gereksinim için yeni bir test ekleyerek, fail -> pass -> refactor olarak yapılır. Son zamanlarda TDD, benzer bir döngüde kabul testleri yazan ATDD'den (BDD'nin bir altkümesi) ayırt etmek için bu döngüdeki birim testleri yazma konusunda daha spesifik hale geldi.
Birim Testi, bir kodu küçük, yalıtılmış birimlerde test etmekle ilgilidir. Buradaki yaygın karışıklık, xUnit veya Rspec gibi bir birim test aracı kullanıyorsanız, birim testleri yazdığınız testleri çalıştırmaktır. Bu mutlaka doğru değildir. Bu araçlar, Selenyum çerçevesini kullanarak sözlü testler yapmak için kullanılabilir - bu durumda, bir birim test koşucusu kullanarak kabul testleri yazıyorsunuz. Birim testleri, hız uğruna her şeyden izole edilen küçük bir mantığa odaklanan testlerdir (böylece sık sık çalıştırabilir ve yeni hatalar hakkında hızlı geri bildirim alabilirsiniz).
TDD, test senaryolarını geliştirme öncesinde söylediğin gibi yazma yaklaşımıdır ve daha sonra geliştirici, test vakalarını geçmek için kodu yazar. Birim Testi, sistem testi, entegrasyon testi ve kabul testi dışında dar kapsamlı bir test türünü tanımlamak için kullanılan bir terimdir.
TDD kod yazmaya felsefi bir yaklaşımdır: önce testleri yazın. Yazdığınız testler birim testlerdir.
Tüm mükemmel cevaplar. TDD entegrasyon ve kabul testlerini içerecek şekilde ölçeklenirken, yalnızca birim testinin 'birim' u küçük bir bileşen olarak görme eğiliminde olduğunu da ekleyeceğim.
(Bazı TDD varyantları 'birimi' istenen işlevselliğe doğru en küçük adım olarak görür ...)
İkisini ayırma şeklim, TDD'nin test etme ve kod tasarlama konusunda daha az olduğunu düşünmektir. Daha sonra, son kod beklentilerini belirlemek için birim testleri kullanılır. Bitiş kodu yazıldığında ve testleri (spesifikasyonlar) geçtiğinde, testler kullanılarak tasarlanan kodunuz olur.