Kod kapsamı analizi için kodu hariç tutmalı mıyız?

Özellikle eski uygulamalar olmak üzere birçok uygulama üzerinde çalışıyorum. Şu anda, kod kapsamları oldukça düşüktür: genellikle% 10 ila 50 arasında.

Birkaç haftadan beri, Bangalore ekipleriyle (gelişimin ana kısmı Hindistan'da denizaşırı yapılır) Cobertura'ya (şu anda JaCoCo'ya geçiş yapıyor olsak bile kod kapsamı aracımız) hariç tutulan tartışmalar hakkında tekrar tekrar tartışıyoruz.

Bakış açıları şöyledir: uygulamanın bazı katmanları (1) üzerinde herhangi bir birim testi yazmayacakları için , bu katmanlar kod kapsamı ölçüsünden kolayca çıkarılmalıdır. Başka bir deyişle, kod kapsamı ölçüsünü sınanan veya sınanması gereken kodla sınırlamak isterler .

Ayrıca, karmaşık bir sınıf için birim testi üzerinde çalıştıklarında, büyük bir uygulama nedeniyle faydalar - sadece kod kapsamı açısından - fark edilmeyecektir. Kod kapsamının kapsamını azaltmak, bu tür çabaları daha görünür hale getirecektir ...

Bu yaklaşımın amacı, uygulamanın test edilebilir olarak değerlendirdiğimiz kısmının mevcut durumunu gösteren bir kod kapsamı ölçütümüz olacaktır .

Ancak benim görüşüm, rakamları bir şekilde taklit ettiğimizdir. Bu çözüm, herhangi bir çaba harcamadan daha yüksek kod kapsamına ulaşmanın kolay bir yoludur. Beni rahatsız eden bir başka nokta şudur: bir haftadan diğerine kapsama artışı gösterirsek, bu iyi haberin geliştiricilerin iyi çalışması mı yoksa sadece yeni istisnalar mı olduğunu nasıl anlayabiliriz?

Ayrıca, kod kapsamı ölçüsünde nelerin dikkate alındığını tam olarak bilemeyiz. Örneğin, kod kapsamının% 40'ına sahip 10.000 satırlık bir kod uygulamam varsa, kod tabanımın% 40'ının test edildiğini düşürebilirim (2) . Ancak istisnalar belirlersek ne olur? Kod kapsamı şimdi% 60 ise, tam olarak ne çıkarabilirim? "Önemli" kod tabanımın% 60'ı test edildi mi? Nasıl yapabilirim

Bildiğim kadarıyla, bu konuda neşeli olamazsak bile, "gerçek" kod kapsamı değerini korumayı tercih ederim. Ayrıca, Sonar sayesinde, kod tabanımızda kolayca gezinebilir ve herhangi bir modül / paket / sınıf için kendi kod kapsamını biliriz. Ancak, elbette, küresel kod kapsamı hala düşük olacaktır.

Bu konuda ne düşünüyorsunuz? Projelerinizde nasılsınız?

Teşekkürler.

(1) Bu katmanlar genellikle UI / Java çekirdekleri vb.

(2) Bunun doğru olmadığını biliyorum. Aslında, bu sadece kod tabanımın% 40'ının

Genellikle Visual Studio'nun oluşturduğu WCF istemcileri gibi otomatik oluşturulan kodu hariç tutarım. Orada genellikle çok sayıda kod satırı vardır ve bunları asla test etmeyeceğiz. Bu, başka bir yerde büyük bir kod parçasındaki testi artırmayı ve kod kapsamını yalnızca% 0.1 arttırmayı çok demoralize ediyor.

Ekip, bu katmanın olabildiğince ince olduğunu kesin olarak söyleyebildiği sürece, veri katmanı etkileşimlerini de hariç tutacağım. Katman ince ise, büyük bir etkisi olmayacağını iddia edebilirken, kapsama raporunda onlara karşı% 0 ile çok fazla bileşen bıraktığını iddia edebiliriz, bu yüzden ihtiyacımız olanları mutlaka fark etmiyoruz gerçekten endişelenmek. UI katmanı, kullanılan çerçeveye bağlı olarak benzer bir şekilde tartışılabilir.

Ancak, bir karşı nokta olarak, birim testlerini de hariç tutacağım. Her zaman ~% 100 kapsama alanına sahip olmalılar ve kod tabanının büyük bir yüzdesini oluşturuyorlar ve rakamları tehlikeli bir şekilde yukarı doğru eğiyorlar.

İyi soru. Genel olarak, bazı nedenlerle kodu kod kapsamı dışında tutma eğilimindedir, örneğin:

• oluşturulan
• eski (artık güncellenmedi)
• işte geliyor: belirli katmanlar, test etmek niyetinde değilim

Neden son nokta? Dikkat dağıtıcı unsurları bastırırken, önem verdiğim şeylere odaklanmak iyi bir uygulama. UI-Layer'ı test etmek istemiyorsanız, neden dikkate alın - bu sadece dikkatinizi yazılımınızın önemli bölümü olan iş mantığından uzaklaştırır.

FAKAT:

1. İyi bir nedeniniz olmalı, neden belirli bir katmanı birim testten hariç tutmalısınız (sorular olabilir - patronunuzdan, takım arkadaşlarınızdan, basından ;-)
2. Bu katmanları test etmelerini istiyorsanız, tüm ekibi göstermek için istatistiklere eklemelisiniz, her gün önemli ve yapılması gerekir.

Son olarak: sayıları çok ciddiye alma. % 30 kapsama alanı, yazılımın sağlam bir parçası olduğunda sağlam bir yazılımı kanıtlayabilir.

Sizinle hemfikirim ve tüm ilgili kodu kod kapsamı metriklerine (ve genel olarak Sonar'a) dahil ediyorum. Kodun bazı bölümlerini (öngörülebilir gelecek için) test etmeyi planlamasanız bile, metrikler gerçek durumu yansıtmalıdır. Bu, kod tabanının önemli bir kısmı için test yazmamanız için zorlayıcı bir nedene sahip olmanızı sağlar. Sonunda (kodun diğer daha önemli kısımları zaten kapsanırsa), bu uyuşmazlığı ortadan kaldırmak için yeniden düşünebilir veya farklı bir yol seçebilirsiniz - örneğin, söz konusu kodu test edilebilir hale getirmek veya yeniden mantığı bir etikete geçirmek için kod tabanının farklı, test edilebilir bir parçası, hatta tüm katmanı tamamen ortadan kaldırmak için (eğer bir katman test edilmeye değmezse, var olmak için yeterince iyi bir nedeni var mı?)

Mevcut projelerimde, tüm kodu metriklere bir istisna dışında ekliyoruz: oluşturulan kod, yığın statik analiz uyarıları üretiyoruz. Bu kod tipik olarak herhangi bir mantığı olmayan humongo POD sınıflarından oluştuğu için, orada test edilecek bir şey yoktur.

Şimdi kullandığınız kod kapsama araçları hakkında çok fazla bilgi sahibi değilim, ne de Java fasulyesine aşina değilim, ama söylediklerinizden UI ile ilgili.

Sınırlı bilgimle şunu söyleyebilirim:

1. Herhangi bir test aracının numaralarının testlerinizle engellenmesine izin vermeyin.
2. Sınıflar karmaşıksa ve birim test edilemezse, bunları daha kompakt ve test edilebilir sınıflara yeniden faktörleştirmek her zaman iyi bir fikirdir. Çok çaba ve özveri gerektirecek, ancak uzun vadede ödeyecek.
3. Kullanıcı arabirimi bileşenlerini sınamak zor olabilir, ancak yine de bu bileşenler tarafından gerçekleştirilen işlevi sınayabilirsiniz.
4. Web tabanlı bir proje yapıyorsanız, tüm istemci tarafı kodunu birim olarak test etmek için QUnit kullanabilirsiniz.

Sonuç olarak, kod kapsamının sadece bir sayı olduğunu ve yüksek kod kapsamının iyi testleri göstermediğini unutmayın. Daha yüksek bir yüzde hedeflemek yerine çekirdek kütüphaneleri daha sağlam ve test edilebilir hale getirmeye odaklanın.

Bazı istisnalar mantıklıdır (projenizin doğru çalışması üzerinde gerçek bir etkisi veya etki potansiyeli olmayan kazan plakası kodu). Yine de kod kapsamını bir metrik olarak toplamak bile anlamsızdır, çünkü zaten faydalı bir şey söylemez. % 100 kod kapsamı gerçek bir hedef değildir ve düşük kapsama alanı sayıları da projeye bağlı olarak kötü olmayabilir,% 20-30 kod kapsamının test edilmeye değer her şeyi kapsaması mümkün olabilir. kod kapsamı, kodunuzun yalnızca% X'inin potansiyel olarak kapsanmaya değer olduğunu söyler, aslında bilinmeyen kalitede bir testtir.

Kodunuzun her katmanı için bir dizi metrik bildirmenizi öneririz. Bu metrikler boyut bilgilerini (ör. LoC, kütüphane sayısı, sınıf veya yöntem sayısı, vb.), Test bilgilerini (ör. Kapsam) ve hata bilgilerini (ör. Bulma ve düzeltme oranları) içermelidir.

Hariç tutulan katmanlarınız% 0 kapsama alanına sahip olacak ve test edilen alanlarınız bahsettiğiniz% 60 kapsama alanına sahip olacak. Boyut bilgisi, insanların ne kadar test edilmediğini veya test edildiğini anlamalarını sağlayacaktır. Hata bilgileri, hariç tutulan katmanlar için testler oluşturmanız gerekip gerekmediğini ve mevcut testlerinizin çalışıp çalışmadığını size bildirir.

Yazılım kuruluşlarının metriklerin saflığına fazla odaklanmaları kolaydır. Metrik yapmıyoruz, iyi yazılım yapıyoruz. Yüksek kaliteli yazılımları zamanında sunmanıza yardımcı olan bir metrik, var olan en dürüst, saf metriktir.