Birim Testleri ve Test Odaklı Gelişim Arasındaki Fark

64

Tanımları okuduktan sonra TDD testlerinde fonksiyon yazmadan önce ve Birim Testinde yapıldığını ve sonrasında yapıldığını anlıyorum.

Bu temel fark mı, yoksa iki terim bile böyle karşılaştırılamaz. Muhtemelen, Birim Testi TDD'nin bütünleşik bir parçasıdır.

unit-testing tdd difference

— Shamim Hafiz
kaynak

104

Birim Testi atıfta neyi test ettiğiniz, TDD için zaman sen test ediyoruz.

İkisi ortogonal.

Birim Testi, bireysel davranış birimlerini test etmek anlamına gelir. Bireysel davranış birimi, bireysel olarak ayrı ayrı test edilebilecek en küçük davranış birimidir. (Bu iki tanımın dairesel olduğunu biliyorum, ancak pratikte oldukça iyi sonuç verdiler.)

Kodunuzu yazmadan önce, kodunuzu yazdıktan sonra veya kodunuzu yazarken birim testleri yazabilirsiniz.

TDD, 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.

TDD'nin en önemli kısmı orta D'dir . Sen testler izin sürücü sizi. Testler size ne yapacağınızı, daha sonra ne yapacağınızı, işiniz bitince söyleyecektir. Size API'nin ne olacağını, tasarımın ne olduğunu söylerler. (Bu önemlidir: TDD ilk önce test yazma ile ilgili değildir. İlk önce test yazma, ancak TDD uygulamayan birçok proje vardır. İlk önce test yazma, testlerin gelişmeyi sürdürebilmesi için ön şarttır.)

— Jörg K Mittag
kaynak

1

Mükemmel cevap. eklemek isterdim ... TDD sizi test etmeye ve gelişim çabalarınızı çekecek özelliklere izin vermenize izin verir ...

— Martin

Yine de ortogonal değiller. Birim testleri olmadan TDD'ye sahip olamazsınız.

— JacquesB

1

@ JacquesB, neden? Testlerimiz, herhangi bir tanımla birim testler dediğiniz şey değildir, altyapıya ve diğer bileşenlere çok fazla bağımlıdırlar, ancak hala en azından bazılarımızın TDD yaptıkları konusunda yeterince gözlemlenebiliriz.

— AProgrammer

3

@AndrewWillems: TDD, testlerin gelişmeyi yönlendirdiği anlamına gelir . Tasarımların neye benzediğine siz karar veremezsiniz, testler size söyler. Bundan sonra ne üzerinde çalışacağınıza siz karar veremezsiniz, testler size söyler. Ne zaman biteceğine siz karar vermediniz, testler size söylüyor. Önce testler yazmak ve sonra size söyledikleri her şeyi görmezden gelmek mükemmel bir şekilde mümkün. Örneğin, önce testleri yazabilirsiniz, ancak daha sonra tüm testler yeşil olduğunda bile kod yazmaya devam edin. Yani, başka bir deyişle: önce sınamalar yazıyorsunuz, ancak sınava yalnızca sınamalar gibi bakıyorsunuz ve gelişmeleri sürdürmelerine izin vermiyorsunuz.

— Jörg W Mittag

1

@ JörgWMittag Ona bakarken saf bir şekilde haklı olabilirsin, ancak TDD'nin siyah beyaz olmadığını da biliyorsun. TDD'nin herhangi bir akıllı kullanımı, testlerin geliştirmeyi tamamen sürmesine izin vermez ve testler kesinlikle tasarımın nasıl göründüğüne kesinlikle karar vermez (belki ünite testleri bunu kısmen yapabilir, ancak daha yüksek bir soyutlama seviyesindeki testleri yapmaz). Yeniden yapılanmaya ne dersiniz? TDD'nin çok önemli bir yönüdür. Ayrıca gerçek dünyada, “testin size söylediği her şeyi görmezden gelin” diye bir şey yoktur. Tanım olarak, önce testleri yazarsanız, 'bir tür TDD' kullanırsınız.

— NickL

21

Birim Testi, Test Odaklı Gelişmenin bir bileşenidir.

Teste dayalı geliştirme yapmadan birim testi yapabilirsiniz. Ancak, birim testlerini kullanmadan teste dayalı geliştirme yapamazsınız.

Geleneksel birim testi yaparken , kodunuzu yazdıktan sonra test yazarsınız .

Test odaklı geliştirme yaklaşımı, kod yazmadan önce birim testi yazmaktır .

TDD'nin (IMHO) basit Ünite Testlerine kıyasla en ilginç avantajları:

Kod tamamen önceden test edilmiş koddur. Acısız test.
Sınıflarınızı doğru tasarlamanız için sizi zorlar.
Aynı zamanda basit aptal tutmak için sizi zorlar .
Kırmızı-Yeşil-Refaktör döngüsü mutlak erteleme katilidir!

Şu ifadede bilerek "birim" i kaçırdın mı: "Ancak, sınama kullanmadan teste dayalı geliştirme yapamazsınız." ?

— ratkok

@ Ratkok: Hayır, bilerek değildi. Bunu düzelteyim.

En çok bu tanımı seviyorum. Diğer cevaplardan daha kelimelerle bir araya getirilmesi daha iyi.

— Tek

2

Muhtemelen, gerçek birim testleri yerine, modül testlerini veya sistem testlerini kullanarak TDD'yi yapabilirsiniz. Testler yapmak çok uzun sürerse, bu avantajı büyük ölçüde kaybettiğiniz için bunu tavsiye etmem ama bu imkansız değildir.

— Toby Speight

13

TDD ve Ünite Testi, sıklıkla kötüye kullanılan iki özel terimdir.

TDD başarısız olacak bir test yazıyor, daha sonra çalışmasını sağlamak için gereken minimum miktarda kod yazıyor, ardından temizlemesi için kodu yeniden düzenliyor. Bu, döngü için, fail -> pass -> refactor olarak yapılır ve kod için bilinen her gereksinim için yeni bir test ekler. Daha yakın bir zamanda TDD, benzer bir döngüde kabul testleri yazan ATDD'den (BDD'nin bir alt kümesi) ayırmak için, bu döngüdeki birim testleri yazma konusunda daha da belirginleşmiştir.

Birim Testi, bir kodu küçük ve yalıtılmış birimlerde test etmekle ilgilidir. Buradaki ortak karışıklık, xUnit veya Rspec gibi bir birim test aracı kullanıyorsanız, birim testleri yazdığınız testleri çalıştırmak olduğunu düşünmektir. Bu mutlaka doğru değil. Bu araçlar Selenyum çerçevesini kullanarak sınama testleri yapmak için kullanılabilir - bu durumda bir birim sınama koşucusu kullanarak kabul sınamaları yazıyorsunuz. Birim testleri, özellikle hız açısından bakılmaksızın her şeyden izole edilen küçük bir mantık parçasına odaklanan testlerdir (böylece sık sık çalıştırıp yeni hatalar hakkında hızlı geri bildirim alabilirsiniz).

— pdr
kaynak

1

JUnit'in kendisi için JUnit testleri iyi bir örnektir: Bunların önemli bir kısmı, JUnit'te yazılmış olsalar bile, birim testler değil fonksiyonel testler ve kabul testleridir. Ayrıca, JUnit'in yaratıcısı aynı zamanda TDD'nin yaratıcısı olur ve JUnit, önemli miktarda fonksiyonel test ve kabul testi kullanılarak TDD kullanılarak geliştirilmiştir. Kabul testi TDD'nin ayrılmaz bir parçasıdır .

— Jörg W Mittag

6

TDD, söylediğiniz gibi test durumlarını gelişimden önce yazma yaklaşımıdır ve ardından geliştirici test durumları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.

— M.Sameer
kaynak

3

TDD kod yazmaya felsefi bir yaklaşımdır: önce testleri yaz. Yazdığınız testler birim testleridir.

— Tangurena
kaynak

1

İkisini ayırmamın yolu TDD'nin test etme konusunda daha az ve kodu tasarlama konusunda daha fazla olduğunu düşünmektir. Son kod beklentilerini ayarlamak için birim testleri kullanılır. Son kod yazıldığında ve testleri geçtiğinde (teknik özellikler), testler kullanılarak tasarlanmış bir kodunuz vardır.

— Grant Palin
kaynak

1

Tüm mükemmel cevaplar. TDD entegrasyon ve kabul testlerini içerecek şekilde ölçeklenirken, ünite testinin sadece 'üniteyi' küçük bir bileşen olarak görme eğiliminde olduğunu eklerdim.

(Bazı TDD değişkenleri 'birimi' istenen işlevselliğe doğru en küçük artımlı adım olarak görür ...)

— Steven A. Lowe
kaynak

yapmalılar, ama gerçekte deneyimlerime göre değil. Şirketler / gruplar TDD'yi yaptıklarını söylüyorlar; tek yaptıkları programcıları jUnit testleriyle ilk teste geçmeye zorlamak, daha sonra geliştirme sırasında QA ve entegrasyon testlerinden kaçınmak (ya da büyük ölçüde azaltmak) için her şeyin zaten test edilmiş olduğu gerçeğini kullanıyorlar.

— jwenting

1

(jwenting, uygulama iddiasında bulunanların eksiklikleri için metodolojiyi suçlamıyor). Herhangi bir araç kötüye kullanılabilir

— Steven A. Lowe

1

Bilmiyorum, fakat TDD'nin teoride olanlarla gerçekte olanlar arasında büyük bir fark olduğunu anlamalısınız. Ve çoğu insan (OP dahil) muhtemelen sadece gerçeği gördüğünde, fark onlara dikkat etmelidir.

— jwenting

TDD'nin tasarım ile ilgili olduğu düşünülürse - neden kabul testini içermeli? tasarımı nasıl "yönlendirir"?

— Vitalii Isaenko

@VitaliiIsaenko kabul testleri, tasarımlar için en üst düzey kapsamı sağlar

— Steven A. Lowe