Kod kapsamı nasıl büyük ölçüde iyileştirilir?

Birim testi altında eski bir uygulama almakla görevlendirildim. İlk uygulama hakkında bazı arka plan: Bu büyük sorunları ile 600k LOC Java RCP kod tabanı

• büyük kod çoğaltma
• enkapsülasyon yok, çoğu özel veri dışarıdan erişilebilir, iş verilerinin bir kısmı da tek ton yaptı, bu yüzden sadece dışarıdan değil her yerden de değiştirilebilir.
• soyutlama yok (örneğin iş modeli yok, iş verileri Nesne [] ve çift [] [] 'de depolanıyor), dolayısıyla OO yok.

İyi bir regresyon test paketi var ve verimli bir KG ekibi hataları test ediyor ve buluyor. Michael Feathers gibi klasik kitaplardan nasıl test edilebileceğinin tekniklerini biliyorum, ama bu çok yavaş. Çalışan bir regresyon test sistemi olduğundan, birim testlerin yazılmasına izin vermek için sistemi agresif bir şekilde yeniden düzenlemekten korkmuyorum.

Hızlı bir şekilde kapsama almak için soruna saldırmaya nasıl başlamalıyım , bu yüzden yönetime ilerleme gösterebilirim (ve aslında JUnit testlerinin güvenlik ağından kazanmaya başlayabilirim)? AgitarOne gibi regresyon testi paketleri oluşturmak için araçlar kullanmak istemiyorum, çünkü bu testler bir şeylerin doğru olup olmadığını test etmiyor.

Birim testleri tanıtmak için hangi kod yerleştirilebilir iki ana eksen olduğuna inanıyorum: A) kod ne kadar test edilebilir? ve B) ne kadar kararlı (yani ne kadar acilen testlere ihtiyacı var)? Sadece uç noktalara bakıldığında, bu 4 kategori verir:

1. Test edilmesi ve kırılgan olması kolay kod
2. Test edilmesi kolay ve kararlı kod
3. Test edilmesi zor ve kırılgan kod
4. Test edilmesi zor ve kararlı kod

Kategori 1, nispeten az çalışma ile çok fazla fayda sağlayabileceğiniz başlangıç ​​noktasıdır. Kategori 2, kapsama istatistikinizi (moral için iyi) hızlı bir şekilde geliştirmenize ve kod tabanı ile daha fazla deneyim kazanmanıza izin verirken, kategori 3 daha fazla (genellikle sinir bozucu) çalışmadır, ancak daha fazla fayda sağlar. İlk yapmanız gereken moral ve kapsama istatistiklerinin sizin için ne kadar önemli olduğuna bağlıdır. Kategori 4 muhtemelen uğraşmaya değmez.

Eski sistemlerde (Java değil) çalışma deneyimim var, bundan çok daha büyük. Kötü haberin taşıyıcısı olmaktan nefret ediyorum, sorununuz sizin probleminizin büyüklüğü. Sanırım hafife aldın.

Eski koda regresyon testleri eklemek yavaş ve pahalı bir işlemdir. Birçok gereksinim iyi belgelenmemiştir - burada bir hata düzeltmesi, orada bir yama ve bunu bilmeden önce yazılım kendi davranışını tanımlar. Testlere sahip olmama, uygulamanın tek başına yapılabileceği anlamına gelir, kodda uygulanan örtük gereksinimleri "zorlamak" için hiçbir test yoktur.

Hızlı bir şekilde kapsama almaya çalışırsanız, muhtemelen işi acele edersiniz, yarı pişirirsiniz ve başarısız olursunuz. Testler, bariz şeylerin kısmi kapsamını verecek ve gerçek meseleleri kapsamaz veya hiç kapsamaz. Satmaya çalıştığınız yöneticileri Birim Testinin buna değmeyeceğine, işe yaramayan başka bir gümüş kurşun olduğuna ikna edeceksiniz.

IMHO, En iyi yaklaşım test etmeyi hedeflemektir. En fazla soruna neden olan kodun% 1 veya% 10'unu tanımlamak için metrikler, bağırsak hissi ve kusur günlüğü raporlarını kullanın. Bu modülleri sertçe vurun ve gerisini görmezden gelin. Çok fazla şey yapmaya çalışmayın, daha azı daha fazladır.

Gerçekçi bir hedef "UT uyguladığımızdan, test altındaki modüllere kusur yerleştirilmesi UT altında olmayanların% x'ine düşmüştür" (ideal olarak x <100'dür).

At zaten civatalandığında ahır kapısı hakkında endişelenmemenizi hatırlattı.

Gerçek şu ki, eski bir sistem için iyi bir test kapsamı elde etmenin maliyet açısından etkili bir yolu yoktur, kesinlikle kısa bir süre içinde değil. MattNz'in de belirttiği gibi, bu çok zaman alıcı bir süreç olacak ve sonuçta aşırı derecede maliyetli olacak. Bağırsam bana, yönetimi etkilemek için bir şey yapmaya çalışırsanız, test etmeye çalıştığınız gereksinimleri tam olarak anlamadan çok hızlı bir şekilde göstermeye çalıştığınız için muhtemelen yeni bir bakım kabusu yaratacağınızı söyler.

Gerçekçi olarak, kodu bir kez yazdıktan sonra, hayati bir şeyi kaçırmak riski olmadan testleri etkili bir şekilde yazmak neredeyse çok geç. Öte yandan, bazı testlerin hiçbir testten daha iyi olduğunu söyleyebilirsiniz, ancak durum buysa, testlerin kendilerinin bir bütün olarak sisteme değer kattıklarını göstermeleri gerekir.

Benim önerim, bir şeyin "bozuk" olduğunu düşündüğünüz kilit alanlara bakmak olacaktır. Demek istediğim, çok verimsiz bir kod olabilir ya da daha önce korumak için pahalı olduğunu gösterebilir. Sorunları belgeleyin ve daha sonra, büyük bir yeniden mühendislik çabasına girmeden sistemi geliştirmenize yardımcı olan bir test seviyesi sunmak için bunu bir başlangıç ​​noktası olarak kullanın. Buradaki fikir, testlere yetişmekten kaçınmak ve bunun yerine belirli sorunları çözmenize yardımcı olacak testler yapmaktır. Bir süre sonra, kodun bu bölümünü korumanın önceki maliyetini ve destekleyici testleriyle uyguladığınız düzeltmelerle ilgili mevcut çabaları ölçüp ayırt edip edemeyeceğinize bakın.

Hatırlanması gereken şey, yönetimin maliyet / fayda ve bunun müşterilerini ve nihayetinde bütçelerini nasıl etkilediğiyle daha fazla ilgilendiğidir. Asla bir şey yapmakla ilgilenmezler çünkü onlara ilgi duyacakları bir fayda sağlayacağını kanıtlayamadıkça yapılacak en iyi şeydir. Sistemi geliştirdiğinizi ve şu anda yaptığınız iş için iyi bir test kapsamı aldığınızı gösterebiliyorsanız, yönetimin bunu çabalarınızın etkili bir uygulaması olarak görme olasılığı daha yüksektir. Bu, ürünün gelişiminin tamamen dondurulmasını talep etmeden veya yeniden yazmak için tartışmak neredeyse imkansız olandan daha da kötüsü, çabalarınızı diğer önemli alanlara genişletme olasılığını tartışmanıza izin verebilir!

Kapsamı geliştirmenin bir yolu daha fazla test yazmaktır.

Başka bir yol da, kodunuzdaki fazlalığı azaltmaktır, böylece mevcut testler şu anda kapsanmayan fazlalık kodunu kapsamaktadır.

A, b ve b 'olmak üzere 3 kod bloğunuz olduğunu varsayalım, burada b', B'nin bir kopyasıdır (tam veya neredeyse eksik kopya) ve test T ile a ve b'de kapsamanız var, ancak b 'değil.

Kod tabanını b 'yi b ve b'den ortaklığını B olarak çıkararak b' yi ortadan kaldıracak şekilde yeniden düzenlerseniz, kod tabanı şimdi a, b0, B, b'0 gibi görünür; b0 b'0 ve vice- ve b0 ve b'0, B'den çok daha küçüktür ve B'yi çağırır / kullanır.

Şimdi programın işlevselliği değişmedi ve ikisi de T testine sahip değil, bu yüzden T'yi tekrar çalıştırabilir ve geçmesini bekleyebiliriz. Şimdi kapsanan kod a, b0 ve B'dir, ancak b'0 değildir. Kod tabanı küçüldü (b'0, b'den küçük!) Kapsama oranımız yükseldi.

Bunu yapmak için, yeniden düzenlemenizi etkinleştirmek için b, b 've ideal olarak B'yi bulmanız gerekir. Bizim CloneDR aracı özellikle Java dahil birçok dil için bunu yapabilirsiniz. Kod tabanınızda çok sayıda yinelenen kod olduğunu söylüyorsunuz; bu sizin yararınıza çalışmanın iyi bir yolu olabilir.

Garip bir şekilde, b ve b 'bulma eylemi, genellikle programın uyguladığı soyut fikirler hakkındaki kelime dağarcığınızı artırır. Aracın b ve b '' nin ne yaptığı hakkında hiçbir fikri olmamakla birlikte, bunları b kodundan ayırma ve b ve b 'içeriğine basit bir şekilde odaklanma eylemi, programcılara genellikle klonlanmış kodun soyutlama B_abstract'ı uyguladığı konusunda çok iyi bir fikir verir. . Bu da kodu anlama anlayışınızı geliştirir. Kendinizi elinize aldığınızda B'ye iyi bir ad verdiğinizden emin olun, daha iyi test kapsamı ve daha sürdürülebilir bir program elde edersiniz.