Bakım sırasında harcanan zamanın yanı sıra geliştirme sırasındaki birim sınamalarının geliştirme zamanındaki etkisi nedir?

Ben bir danışmanım ve müşteri sitemdeki tüm geliştiricilere birim testleri tanıtacağım. Amacım, tüm yeni uygulamaların oluşturulan tüm sınıflar için birim testlerinin yapılmasını sağlamaktır.

Müşterinin mevcut uygulamalarındaki hataları gidermekten kaynaklanan yüksek bakım maliyetleri ile ilgili bir sorunu var. Uygulamaları, sürekli olarak yeni özellikler ekledikleri 5-15 yıl arasında bir ömre sahiptir. Birim testlerine başlamaktan büyük fayda sağlayacağına eminim.

Birim testlerinin geliştirme zamanına ve maliyetine olan etkisiyle ilgileniyorum:

• Geliştirme sürecinin bir parçası olarak birim testleri yazmak ne kadar zaman katacaktır?
• İyi ünite testleri uygulayarak bakım faaliyetlerinde (test ve hata ayıklama) ne kadar zaman kazanacaksınız?

Geliştirme sırasında birim kodlama oluştururken uygulamaların sadece kodlamaya kıyasla daha ne kadar süreceğini gösteren herhangi bir istatistik var mı?

Bununla ilgili çok ilginç bir araştırma var. Aşağıdaki teknik incelemeyi okuyun:

Test odaklı geliştirme yoluyla kalitenin iyileştirilmesi: dört sanayi ekibinin sonuçları ve deneyimleri

Teknik inceleme ve diğerleri, yazarlarından Nachi Nagappan'dan araştırmalar burada tartışılmaktadır: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Çalışma ve sonuçları, test odaklı geliştirme yoluyla kalitenin iyileştirilmesi gerçekleştirilmesi başlıklı bir makalede yayınlandı: Nagappan ve araştırma görevlileri E. Almaden Araştırma Merkezi'nden E. Michael Maximilien; Microsoft'taki başlıca yazılım geliştirme lideri Thirumalesh Bhat; ve North Carolina State Üniversitesi'nden Laurie Williams. Araştırma ekibinin buldukları, TDD ekiplerinin, TDD olmayan ekiplere göre hata yoğunluğu açısından yüzde 60 ila 90 daha iyi kod ürettikleriydi. Ayrıca TDD ekiplerinin projelerini tamamlamak için daha uzun sürdüğünü de keşfetti - yüzde 15 ila 35 daha uzun.

Nagappan, “12 aylık bir gelişim döngüsü boyunca yüzde 35, devasa bir başka dört ay” dedi. “Ancak, kod çözme kalitesi çok daha iyi olduğu için, piyasaya çıkma sonrası bakım maliyetlerini önemli ölçüde azalttığınız için bu durum değişiyor. Yine, bunlar yöneticilerin alması gereken kararlardır - nereye vurmalılar? Ancak şimdi, bu kararları vermek için aslında nicel veriye sahipler. ”

Ayrıca, Jason Gorman , bu yıl Yazılım İşçiliği konferansı için böyle bir deneme önerdi . TDD ve TDD olmayan bir yaklaşım kullanarak aynı uygulamayı yaratan bir deneme yapmaya çalışıyordu ve yakın zamanda sonuçları hakkında blog yazdı :

3 yinelemenin üzerinde, kadayı TDD'siz tamamlamak için geçen ortalama süre 28m 40s idi. TDD ile ortalama süre 25m 27s idi. TDD olmadan ortalama olarak 5.7 geçiş yaptım (kabul testine girerek). TDD ile ortalama olarak 1.3 geçiş yaptım (iki denemede ilk kez geçtiler, birinde 2 geçiş aldı).

Şimdi, bu elbette bir bebek deneyiydi. Ve tam olarak laboratuar koşulları değil. Ama aynı şekilde birkaç ilginç şey olduğuna dikkat edin.

Daha fazla insan gerçekleştirdiğinde, bu deneyin sonuçlarını görmek ilginç olacaktır.

(İyi) birim testlerinde bakımın kaç saat azaldığını gösteren herhangi bir istatistik var mı?

Yukarıdaki teknik incelemeden:

Vaka çalışmalarının sonuçları, dört ürünün ön salım öncesi kusur yoğunluğunun TDD uygulamasını kullanmayan benzer projelere göre% 40 ile% 90 arasında azaldığını göstermektedir.