TDD'nin Kaliteyi ve / veya Geliştirme Hızını Nasıl Geliştirdiğine İlişkin Örnek Olaylar Aranıyor [kapalı]

Şirketimde neden TDD yapmamız gerektiğine dair bir dava açmaya çalışıyorum. Şu anda çoğu geliştirici sadece projeyi tamamlamak için ellerinden geleni yapıyor, sonra yönetici metriklerini karşılamak için daha sonra birim testleri ekliyorlar. TDD yapan ve faydalarını gören saygın şirketlerden örnekler çok takdir edilecektir.

IBM ve Microsoft'ta 4 projenin incelenmesi. Yayınlandığı empirik Yazılım Mühendisliği dergisinde.

Ampirik Çalışmalar Test Odaklı Geliştirmenin Kaliteyi Artırdığını Göster

Ampirical Software Engineering dergisi raporunda ilk kez yayınlanan bir raporda: "TDD çeşitli alanlarda uygulanabilir gibi görünüyor ve geliştirme ekibinde verimlilikte önemli bir azalma olmadan geliştirilen yazılımın hata yoğunluğunu önemli ölçüde azaltabilir." Çalışma, Microsoft ve IBM'de TDD'yi TDD kullanmayan benzer projelerle kullanan 4 projeyi karşılaştırdı ...

Bu makale, IBM'de 1 ve Microsoft'tan 3 vaka çalışması içermektedir. Vaka çalışmalarının her biri, aynı geliştirme dillerini ve teknolojilerini kullanarak, aynı test üzerinde geliştirme (TDD) kullanan aynı üst düzey yönetici altında aynı ürün üzerinde çalışan iki takımı karşılaştırır. Hiçbir ekip, gelişim döngüleri boyunca çalışmanın bir parçası olacaklarını bilmiyordu. IBM örnek olay incelemesi, aygıt sürücüsü geliştirme yapan ekipleri izledi. Microsoft vakaları Windows, MSN ve Visual Studio üzerinde çalışan ekipleri izledi.

Makale, ekipler tarafından kullanılan TDD uygulamalarını dakikadan dakikaya iş akışları ve görev düzeyinde iş akışları olarak tanımlamaktadır ...

TDD hakkında, "Yazılım Yapımı: Neyin işe yaradığını ve neden inandığımızı" anlatan bir vaka çalışmasının yer aldığı bir bölüm var. Ancak hayal kırıklığına uğrayabilirsiniz, çünkü doğru hatırlarsam çalışma TDD'ye herhangi bir gerçek fayda ortaya çıkarmadı. Vaka çalışması zaten ilginçti ve genel olarak kitap, son zamanlarda okuduğum en iyi yazılım kitaplarından biri. Çift programlama, kod incelemesi, vb. Gibi birçok vaka çalışması içerir.

Kesinlikle bu göz atın : TDD Etkili Kanıtlanmış! Yoksa öyle mi?

... Phil Haack, Araştırmaların TDD'nin Etkinliğini Desteklediğini açıkladığında , bağlantılı raporun gerçekte ne içerdiğini görmekle biraz ilgilendim . Phil özetinden alıntılar.

Test ilk önce gelen öğrencilerin ortalama olarak daha fazla test yazdıklarını ve daha fazla test yazan öğrencilerin daha verimli olma eğiliminde olduklarını gördük. Ayrıca, asgari kalitenin kullanılan geliştirme stratejisinden bağımsız olarak programcı testi sayısı ile doğrusal olarak arttığını gözlemledik.

Phil, raporun geri kalanını açık bir şekilde okudu ve başlığının da belirttiği gibi sevdiği parçaları sunuyor. Bununla birlikte, en son ve en büyük yazılım geliştirme uygulamalarını destekleyen şeyleri gördüğümde endişelendiğim şeylerden biri, mevcut teorilerin onaylanması ve karşı göstergelerin gözden geçirilmesi için onay yanlılığına yönelik güçlü bir eğilim .

Bu yüzden, meraklı bir tür olarak ve TDD bir gün kendimi benimsemek isteyebileceğim bir şey olup olmadığını görmek için gözümde tuttuğum bir şey olduğu için rapora girdim ...

... hiç şüphesiz, test ilk önce fonksiyonel ünite başına daha fazla test yapılmasına yol açar. Soru, bunun değerli olup olmadığıdır. Bu çalışma, en azından kalite sizin amaçladığınız kazançsa, muhtemelen böyle olmadığını gösteriyor gibi görünmektedir. Ama sonra, kodların sayısının üretkenliğe karşılık gelmediğine şaşırmadım gibi, testlerin sayısının kaliteye karşılık gelmediğine şaşırmadım.

Yazar, TDD'nin bu kadar etkili olmadığı konusunda çok iyi noktalara sahip (imo'ya rağmen imo)

sizin ve müşterinizin yazılımı manuel olarak test etmek için ne kadar zaman harcadıklarına bakın; bunu TDD tarzı otomatik testlerin ne kadar süreceği tahminiyle karşılaştırın. Farkı cep haline getir

Tecrübelerime göre, TDD'nin otomatik testleri altındır çünkü sigorta sağlarlar ve çok sayıda manuel testi ortadan kaldırırlar

Andres F'nin belirttiği gibi, bu faydaları sadece TDD'den değil, yalnızca otomatik testlerden alabilirsiniz - ancak TDD , sonradan düşünülen veya olması hoş bir şey olmak yerine otomatik testler gerektirir

Önce test hakkında düşünmeye zorlanmak, kod yazmaya başlamadan önce sizi modülerlik, arayüz tasarımı ve benzeri gibi kalite ile ilgili sorunları düşünmeye zorlar.

Şahsen, TDD'nin en büyük faydalarından birinin, testi yazmanın, kodu yazarken değil, kod yazarken zihninizde gerçekten ne yapması gerektiğinin özelliklerini tuttuğuna inanıyorum. gibi--you-kodu.

bunun için bir dava açmak istersiniz: bir sonraki proje için yapmanızı ve ardından ondan ders almanızı öneririz. Görünüşe göre sizin için harika çalışıyor, umarım kullanmaya devam edersiniz ve projeyi yapmak ve / veya kod yazmak yerine tüm zamanınızı yazmak için harcamak daha uzun sürerse, kesinlikle başarısızlık.

Bence gerçek dünya çözümü (çoğu şey gibi) bir orta yol, testler istiyorsunuz ama testlerin projeden daha önemli olmasını istemiyorsunuz.

(kişisel olarak TDD'nin bir heves olduğunu düşünüyorum, teoride kulağa hoş geliyor, ama pratikte ... çok iyi değil. Entegrasyon testinin çok daha önemli olduğunu düşünüyorum, ancak bu sadece üzerinde çalıştığım karmaşık projeler olabilir).

TDD'yi 2 yıldır çalışıyorum ve o zaman çalıştığım yerde, yöneticiler de dahil olmak üzere kullanmakta isteksizdik.Ancak yakında yapılacak doğru şey haline geldi.

• Erken bir aşamada hataları keşfetmek.
• Farkında olmadan daha iyi kod yazma.
• Testiniz nedeniyle küçük parçalar halinde (300-400 satır olan işlevlerimiz vardı) aptalca olduğundan kodunuz artık daha sürdürülebilir. Şimdi maksimum 30 ve hepsi bağımsız olarak test edildi.

Yöneticiler hepsi bir şey "Bitirdiniz" ilgileniyor gibi bilmiyordum. Ama sonra yazılım farkında olmadan kırılmaya devam ettiğinde şikayet ediyorlar. İyi bir kapsama alanı ve mantıklı testlerle.Birisi bir işlevi kırdığında gerçekten görebileceğiniz miktar değil kalite. Ayrıca ne yazık ki kendi başınıza iseniz zordur.Yani yazılımın parçalarını test edilebilir hale getirebilmeniz için kodu örneğin temel sınıflar vb. Değiştirmeniz gerekebilir.

Depoyu taklit etmek istedim ama hiçbir arayüz yoktu ve depoyu hizmet katmanıma enjekte etmem ve bu nedenle dükkanın her tarafına bir kurucu eklemek / değiştirmek gerekiyor, bu büyük bir şey olduğu ortaya çıktı ama sonunda ben sadece sistemin bir alanını test 200'den fazla test var ve onlar etkilendiler.

Genellikle aşağıdakileri yaparım:

• Birim testlerimi çok kısa tutuyorum
• Sadece 1 iddia. Rus ruleti yok.
• Pozitif-negatif ve istisna senaryosunu test ediyorum

Korkarım vaka çalışmaları ile ilgili olarak, gördüğümden emin değilim. Projenizi inşa etmeniz ve örnek olaylarınız olmanız gerekiyor.

Umut ediyorum bu yardım eder