Birim testleri için, belki de bir depoya giriş için bir gereklilik olarak bile, minimum kod yüzdesini zorunlu kılsaydınız, bu ne olurdu?

Lütfen cevabınıza nasıl ulaştığınızı açıklayın (çünkü yaptığınız tek şey bir numara seçmek olsaydı, bunu kendim yapabilirdim;)

Alberto Savoia'nın bu nesir tam olarak bu soruya cevap veriyor (bu konuda eğlenceli bir şekilde!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Test Kapsamında Testivus

Bir sabah erkenden, bir programcı büyük ustaya sordu:

“Bazı birim testleri yazmaya hazırım. Hangi kod kapsamını hedeflemeliyim? ”

Büyük usta cevap verdi:

“Kapsam hakkında endişelenme, sadece iyi testler yaz.”

Programcı gülümsedi, eğildi ve gitti.

...

O günün ilerleyen saatlerinde, ikinci bir programcı aynı soruyu sordu.

Büyük üstat kaynar su kabına işaret etti ve şöyle dedi:

“Bu tencereye kaç tane pirinç tanesi koymalıyım?”

Şaşkın görünen programcı yanıtladı:

“Sana nasıl söyleyebilirim? Bu, kaç kişiyi beslemeniz gerektiğine, ne kadar aç olduklarına, başka hangi yiyeceklere hizmet ettiğinize, ne kadar pilavınız olduğuna vb. Bağlıdır. ”

"Kesinlikle," dedi büyük usta.

İkinci programcı gülümsedi, eğildi ve gitti.

...

Günün sonuna doğru üçüncü bir programcı geldi ve aynı soruyu kod kapsamı hakkında sordu.

“Yüzde seksen ve daha az değil!” Ustayı sert bir sesle yanıtladı, yumruğunu masaya vurdu.

Üçüncü programcı gülümsedi, eğildi ve gitti.

...

Bu son cevaptan sonra genç bir çırak büyük ustaya yaklaştı:

“Büyük usta, bugün aynı soruya üç farklı cevapla cevap verdiğinizi duydum. Neden?"

Büyük üstat sandalyesinden kalktı:

"Gel benimle biraz çay iç ve bunun hakkında konuşalım."

Bardaklarını sıcak yeşil çay içerek doldurduktan sonra, büyük usta cevap vermeye başladı:

“İlk programcı yeni ve teste yeni başladım. Şu anda çok fazla kodu var ve testleri yok. Uzun bir yolu var; şu anda kod kapsamına odaklanmak iç karartıcı ve oldukça işe yaramaz olacaktır. Sadece bazı testler yazmaya ve yapmaya alışmak daha iyidir. Daha sonra kapsama alanı hakkında endişelenebilir. ”

“Öte yandan, ikinci programcı hem programlama hem de test etme konusunda oldukça deneyimlidir. Bir tencereye kaç tane pirinç tanesi koymam gerektiğini sorduğumda, gerekli test miktarının bir dizi faktöre bağlı olduğunu fark etmesine yardımcı oldum ve bu faktörleri benden daha iyi biliyor - sonuçta onun kodu . Tek, basit, cevap yoktur ve gerçeği idare edecek ve onunla çalışacak kadar zeki. ”

“Görüyorum,” dedi genç çırak, “ama tek bir basit cevap yoksa, neden üçüncü programcıya 'yüzde seksen ve daha az değil' diye cevap verdiniz?”

Büyük usta o kadar sert ve gürültülü güldü ki karnı, sadece yeşil çaydan daha fazla içtiğinin kanıtı, yukarı ve aşağı yüzdü.

“Üçüncü programcı sadece basit cevaplar istiyor - basit cevaplar olmasa bile… ve sonra yine de takip etmiyor.”

Genç çırak ve kırlaşmış büyük usta, düşünceli sessizlikte çaylarını içmeyi bitirdi.

% 100 kapsama alanı hedefinizse Kod Kapsamı yanıltıcı bir metriktir (tüm özelliklerin% 100 test edilmesi yerine).

• Tüm çizgilere bir kez vurarak% 100 alabilirsiniz. Bununla birlikte, bu satırların vurulduğu belirli bir diziyi (mantıksal yol) test etmeyi yine de kaçırabilirsiniz.
• % 100 alamadınız, ancak yine de% 80 / freq kullanılan tüm kod yollarını test ettiniz. Koyduğunuz her 'throw ExceptionTypeX' veya benzer savunma amaçlı programlama görevlisini test eden testlere sahip olmak 'sahip olmak güzel' değil 'sahip olmak'

Bu yüzden, kendinize veya geliştiricilerinize kapsamlı olmalarına ve kodları aracılığıyla her yolu kapsamasına güvenme. Pragmatik olun ve büyülü% 100 kapsamı takip etmeyin. Kodunuzu TDD yaparsanız, bonus olarak% 90 + kapsama alanı almanız gerekir. Kaçırdığınız kod parçalarını vurgulamak için kod kapsamını kullanın (yine de TDD yaparsanız olmamalıdır .. çünkü sadece bir test geçişi yapmak için kod yazdığınız için. Ortak testi olmadan kod bulunamaz.)

Kod kapsamı harika, ancak işlevsellik kapsamı daha da iyi. Yazdığım her satırı kapsama inanmıyorum. Ancak, sunmak istediğim tüm işlevlerin% 100 test kapsamını yazmaya inanıyorum (kendimle geldiğim ve toplantılarda tartışılmayan ekstra harika özellikler için bile).

Ben testlerde kapsanmayan kod olurdu umurumda değil, ama benim kod refactor ve farklı bir davranış sahip sonunda umurumda olur. Bu nedenle,% 100 işlevsellik kapsamı benim tek hedefim.

Kabul edilen cevap iyi bir noktaya işaret ediyor - her proje için bir standart olarak anlamlı olacak tek bir sayı yok. Böyle bir standarda ihtiyaç duymayan projeler var. Kabul edilen cevabın yetersiz kaldığı yerde, bence, bir kişinin belirli bir proje için bu kararı nasıl alabileceğini açıklamaktır.

Bunu yaparken bir çekim yapacağım. Test mühendisliğinde uzman değilim ve daha bilinçli bir cevap gördüğüme sevinirim.

Kod kapsamı gereksinimleri ne zaman ayarlanmalı

Birincisi, neden ilk etapta böyle bir standart uygulamak istesin ki? Genel olarak, sürece ampirik güveni tanıtmak istediğinizde. "Ampirik güven" ile ne demek istiyorum? Gerçek hedef doğruluğu . Çoğu yazılım için, bunu tüm girişlerde bilemeyiz, bu nedenle kodun iyi test edildiğini söylemeye karar verdik . Bu daha bilinebilir, ama yine de öznel bir standarttır: Onu karşılayıp karşılamadığınız her zaman tartışmaya açık olacaktır. Bu tartışmalar faydalıdır ve gerçekleşmelidir, fakat aynı zamanda belirsizliği de ortaya çıkarırlar.

Kod kapsamı nesnel bir ölçümdür: Kapsam raporunuzu gördüğünüzde, standartların karşılanıp karşılanmadığına dair bir belirsizlik yoktur. Doğruluğunu kanıtlıyor mu? Hiç de değil, ancak kodun ne kadar iyi test edildiğiyle açık bir ilişkisi var, bu da doğruluğuna olan güveni artırmanın en iyi yoludur. Kod kapsamı, önem verdiğimiz ölçülemeyen niteliklerin ölçülebilir bir yaklaşımıdır.

Ampirik bir standarda sahip olmanın değer katabileceği bazı özel durumlar:

• Paydaşları tatmin etmek.Birçok proje için, yazılımın günlük gelişimine dahil olmayabilecek yazılım kalitesine ilgi duyan çeşitli aktörler vardır (yöneticiler, teknik liderler, vb.) gerçekten ihtiyacımız olan testler "inandırıcı değil: Ya tamamen güvenmeleri ya da sürekli yakından gözetim ile doğrulamaları gerekiyor (bunu yapmak için teknik anlayışa sahip olduklarını varsayarak.) Ölçülebilir standartlar sağlamak ve gerçek hedeflere ne kadar makul bir şekilde yaklaştıklarını açıklamak daha iyidir.
• Takım davranışını normalleştirmek.Paydaşlar bir yana, eğer birden fazla kişinin kod ve test yazdığı bir ekip üzerinde çalışıyorsanız, "iyi test edilmiş" niteliklere göre belirsizliğe yer vardır. Tüm meslektaşlarınız hangi test düzeyinin yeterince iyi olduğu konusunda aynı fikre sahip mi? Muhtemelen değil. Bunu nasıl uzlaştırıyorsunuz? Hepinizin hemfikir olabileceği bir metrik bulun ve bunu makul bir yaklaşım olarak kabul edin. Bu, özellikle (yalnızca değil), potansiyel müşterilerin küçük geliştiriciler üzerinde doğrudan gözetim altında olamayacağı büyük ekiplerde yararlıdır. Güven ağları da önemlidir, ancak nesnel ölçümler olmadan, herkes iyi niyetle hareket etse bile, grup davranışının tutarsız hale gelmesi kolaydır.
• Kendinizi dürüst tutmak için. Projeniz için tek geliştirici ve tek paydaş olsanız bile, yazılım için belirli niteliklere sahip olabilirsiniz. Yazılımın ne kadar iyi test edildiğine (işe yarar) ilişkin sürekli öznel değerlendirmeler yapmak yerine, kod kapsamını makul bir yaklaşım olarak kullanabilir ve makinelerin sizin için ölçmesine izin verebilirsiniz.

Hangi metrikler kullanılacak

Kod kapsamı tek bir metrik değildir; kapsamı ölçmenin birkaç farklı yolu vardır. Hangisini bir standart oluşturabileceğinizi karşılamak için bu standardı kullandığınız şeye bağlıdır.

Standartları belirlemek için bunları ne zaman kullanabileceğinize örnek olarak iki yaygın metriği kullanacağım:

• Bildirim kapsamı : Testler sırasında ifadelerin yüzde kaçı yürütüldü? Bir anlamda almak için Faydalı fiziksel kapsama Ben aslında test ettik yazdım kod Ne kadar: kodunuzun?
  • Bu tür bir kapsam daha zayıf bir doğruluk argümanını destekler, ancak başarılması da daha kolaydır. Sadece emin olmak için kod kapsama kullanıyorsanız o şeyler (bunun ötesinde deney kalitesinin bir göstergesi olarak değil) test ediliyor sonra beyanı kapsamı muhtemelen yeterlidir.
• Dal kapsamı : Dallanma mantığı (örneğin bir if) olduğunda, her iki dal da değerlendirildi mi? Bu, kodunuzun mantıksal kapsamı hakkında daha iyi bir fikir verir : Kodumun alabileceği olası yollardan kaçını test ettim?
  • Bu tür bir kapsam, bir programın kapsamlı bir girdi kümesinde test edildiğinin çok daha iyi bir göstergesidir. Doğruluğa güvenmek için kod kapsamını en iyi ampirik yaklaşımınız olarak kullanıyorsanız, şube kapsamına veya benzerine göre standartlar belirlemelisiniz.

Başka birçok metrik vardır (satır kapsamı ifade kapsamına benzer, ancak çok satırlı ifadeler için farklı sayısal sonuçlar verir; koşullu kapsam ve yol kapsamı şube kapsamına benzer, ancak olası permütasyonların daha ayrıntılı bir görünümünü yansıtır. karşılaşabileceğiniz program yürütme.)

Ne kadarlık yüzde

Son olarak, asıl soruya dönelim: Kod kapsamı standartlarını belirlerseniz, bu sayı ne olmalıdır?

Umarım bu noktada başlamak için bir yaklaşımdan bahsediyoruz, bu yüzden seçtiğimiz herhangi bir sayı doğal olarak yaklaşık olacak.

Birinin seçebileceği bazı sayılar:

• % 100 . Bunu seçebilirsiniz çünkü her şeyin test edildiğinden emin olmak istersiniz. Bu size test kalitesi hakkında herhangi bir fikir vermez, ancak bazı kalite testlerinin her ifadeye (veya şubeye vb.) Dokunduğunu söyler. Yine, bu güven derecesine geri döner: Kapsamınız% 100'ün altındaysa , kodunuzun bazı alt kümelerinin test edilmediğini biliyorsunuz .
  • Bazıları bunun saçma olduğunu iddia edebilir ve kodunuzun sadece gerçekten önemli olan kısımlarını test etmelisiniz. Kodunuzun sadece gerçekten önemli olan kısımlarını da korumanız gerektiğini iddia ediyorum. Test kapsamı test edilmemiş kod kaldırılarak da geliştirilebilir.
• % 99 (veya% 95, yüksek doksanlardaki diğer sayılar.) % 100'e benzer bir güven düzeyi iletmek istediğiniz durumlarda uygundur , ancak test edilmesi zor köşesi hakkında endişelenmemek için kendinize biraz marj bırakın kodu.
• % 80 . Bu sayıyı birkaç kez kullanımda gördüm ve nereden geldiğini tam olarak bilmiyorum. Ben düşünüyorum da 80-20 üstünlüğü garip bir zimmet olabilir; genel olarak, burada amaç kodunuzun çoğunun test edildiğini göstermektir . (Evet,% 51'i de "en" olur, ancak% 80'i çoğu insanın en çok ne anlama geldiğini daha fazla yansıtır .) Bu, "iyi test edilmiş" in yüksek önceliğe sahip olmadığı orta dereceli davalar için uygundur ( Düşük değerli testler için çaba harcamak istemiyorsanız), ancak yine de bazı standartların mevcut olmasını istediğiniz bir öncelik yeterlidir.

Pratikte% 80'in altında rakamlar görmedim ve bir kişinin bunları belirleyeceği bir vakayı hayal etmekte zorlandım. Bu standartların rolü, doğruluğa olan güveni arttırmaktır ve% 80'in altındaki rakamlar özellikle güven verici değildir. (Evet, bu özneldir, ancak yine de, standardı belirlediğinizde öznel seçimi bir kez yapmak ve daha sonra ileriye yönelik objektif bir ölçüm kullanmaktır.)

Diğer notlar

Yukarıda belirtilen doğruluk hedeftir. Kod kapsamı sadece bilgidir; diğer hedeflerle ilgili olabilir. Örneğin, sürdürülebilirlik konusunda endişeleriniz varsa, muhtemelen test edilebilirlikle gösterilebilen gevşek kodlamayı önemsersiniz, bu da kod kapsamı ile ölçülebilir (belirli modalarda). Dolayısıyla, kod kapsamı standardınız "sürdürülebilirlik" in kalitesini tahmin etmek için ampirik bir temel sağlar.

Favori kod kapsamım bir yıldız işaretiyle% 100. Yıldız işareti geliyor çünkü belirli satırları "sayılmayan" satırlar olarak işaretlememe izin veren araçlar kullanmayı tercih ediyorum. "Sayılan" çizgilerin% 100'ünü kapsaydım, işim bitti.

Temel süreç:

1. Testlerimi düşünebildiğim tüm işlevleri ve son durumları uygulamak için yazıyorum (genellikle belgelerden çalışarak).
2. Kod kapsamı araçlarını çalıştırıyorum
3. Kapsamayan satırları veya yolları ve önemli veya ulaşılamaz olduğunu düşündüğüm herhangi bir şeyi (savunma programlaması nedeniyle) inceliyorum saymıyorum olarak işaretliyorum
4. Eksik hatları kapsamak için yeni testler yazıyorum ve bu uç durumlardan bahsedilmiyorsa belgeleri geliştiriyorum.

Bu şekilde ben ve işbirlikçilerim yeni kod ekler veya gelecekte testleri değiştirirsek, önemli bir şeyi kaçırıp kaçırmadığımızı bize bildiren parlak bir çizgi var - kapsam% 100'ün altına düştü. Bununla birlikte, farklı test öncelikleriyle başa çıkma esnekliği de sağlar.

Paylaşmak istediğim test kapsamı hakkında başka bir anekdotum daha olurdu.

Büyük bir projemiz var, twitter üzerinden 700 birim test ile sadece% 20 kod kapsamına sahibiz .

Scott Hanselman , bilgelik sözleriyle yanıtladı :

% 20 DOĞRU mu? Kullanıcılarınızın en çok vurduğu kodu temsil eden% 20 mi? 50 test daha ekleyebilir ve yalnızca% 2 ekleyebilirsiniz.

Yine, Kod Kapsamı Testivus'uma geri dönüyor . Tencereye ne kadar pirinç koymalısınız? Değişir.

Birim testlerin geliştirmeyi baştan beri yönlendirdiği iyi tasarlanmış bir sistem için% 85'in oldukça düşük bir sayı olduğunu söyleyebilirim. Test edilebilir olacak şekilde tasarlanmış küçük sınıfların bundan daha iyi kapsanması zor olmamalıdır.

Bu soruyu aşağıdaki gibi bir şeyle reddetmek kolaydır:

• Kapsanan çizgiler test edilen mantığa eşit değildir ve yüzde olarak çok fazla okunmamalıdır.

Doğru, ancak kod kapsamı hakkında yapılması gereken bazı önemli noktalar var. Deneyimlerime göre, bu metrik doğru kullanıldığında aslında oldukça yararlıdır. Bunu söyledikten sonra, tüm sistemleri görmedim ve eminim ki kod kapsamı analizinin gerçek bir değer kattığını görmek zor. Kod çok farklı görünebilir ve mevcut test çerçevesinin kapsamı değişebilir.

Ayrıca, akıl yürütmem esas olarak oldukça kısa test geri bildirim döngüleri ile ilgilidir. En kısa geri besleme döngüsünü geliştirdiğim ürün için sınıf testlerinden süreçler arası sinyalizasyona kadar her şeyi kapsayan oldukça esnektir. Teslim edilebilir bir alt ürünün test edilmesi tipik olarak 5 dakika sürer ve böyle kısa bir geri besleme döngüsü için, depodaki taahhütleri reddetmek veya kabul etmek için test sonuçlarını (ve özellikle burada baktığımız kod kapsamı metriğini) kullanmak gerçekten mümkündür.

Kod kapsamı metriğini kullanırken, yalnızca yerine getirilmesi gereken sabit (keyfi) bir yüzdeye sahip olmamalısınız. Bunu yapmak, bence kod kapsamı analizinin gerçek faydalarını sağlamaz. Bunun yerine, aşağıdaki metrikleri tanımlayın:

• Düşük Su İşareti (LWM), test edilen sistemde şimdiye kadar görülen en düşük açık hat sayısı
• Yüksek Su İşareti (HWM), test edilen sistem için şimdiye kadar görülen en yüksek kod kapsama yüzdesi

Yeni kod ancak LWM'nin üzerine çıkmazsak ve HWM'nin altına inmezsek eklenebilir. Başka bir deyişle, kod kapsamının azalmasına izin verilmez ve yeni kodun kapsaması gerekir. Nasıl söylemeliyim ve olmamalı (aşağıda açıklanmıştır) dikkat edin.

Ancak bu, artık iyi kullanmadığınız eski iyi test edilmiş çöpleri temizlemenin imkansız olacağı anlamına gelmiyor mu? Evet, bu yüzden bu şeyler hakkında pragmatik olmalısınız. Kuralların çiğnenmesi gereken durumlar vardır, ancak tipik günlük entegrasyonunuz için deneyimlerim, bu metriklerin oldukça yararlı olduğunu göstermektedir. Aşağıdaki iki sonucu vermektedirler.

• Test edilebilir kod yükseltilir. Yeni kod eklerken, kodu test edilebilir yapmak için gerçekten çaba göstermelisiniz, çünkü hepsini test senaryolarınızla kapsamak zorunda kalacaksınız. Test edilebilir kod genellikle iyi bir şeydir.

• Eski kodun test kapsamı zamanla artmaktadır. Yeni kod eklerken ve bir test senaryosuyla kaplanamadığında, LWM kuralını aşmak için eski kodu kapsamayı deneyebilirsiniz. Bu bazen gerekli hile en azından eski kodun kapsamının zamanla artacağı olumlu yan etkiyi verir ve bu kuralların görünüşte sıkı bir şekilde uygulanmasını pratikte oldukça pragmatik hale getirir.

Ve yine, geri besleme döngüsü çok uzunsa, entegrasyon sürecinde böyle bir şey kurmak tamamen pratik olmayabilir.

Ayrıca kod kapsamı metriğinin iki genel avantajından daha bahsetmek istiyorum.

• Kod kapsamı analizi, dinamik kod analizinin bir parçasıdır (statik olanın aksine, yani Lint). Dinamik kod analizi sırasında bulunan sorunlar (saflaştırma ailesi, http://www-03.ibm.com/software/products/en/rational-purify-family gibi araçlarla ) başlatılmamış bellek okumaları (UMR), bellek sızıntıları, vb. Bu sorunlar yalnızca kod yürütülen bir test senaryosunun kapsamındaysa bulunabilir . Bir test durumunda kapsaması en zor olan kod genellikle sistemdeki anormal durumlardır, ancak sistemin zarif bir şekilde başarısız olmasını istiyorsanız (yani çökme yerine hata izlemesi) anormal durumları kapsamak için biraz çaba harcamak isteyebilirsiniz. dinamik kod analizinde. Sadece biraz kötü şansla, bir UMR bir segfault veya daha kötüye yol açabilir.

• İnsanlar yeni kod için% 100'lük bir gurur duyuyor ve insanlar test problemlerini diğer uygulama problemlerine benzer bir tutkuyla tartışıyorlar. Bu işlev nasıl daha test edilebilir bir şekilde yazılabilir? Bu anormal vakayı, vb. Örtmeye nasıl çalışırsınız?

Ve negatif, bütünlük için.

• İlgili birçok geliştiricinin bulunduğu büyük bir projede, herkes kesin bir test dehası olmayacak. Bazı insanlar, kod kapsamı metriğini, kodun test edildiğinin kanıtı olarak kullanma eğilimindedir ve bu sorunun diğer cevaplarının çoğunda belirtildiği gibi , bu gerçeklerden çok uzaktır . Düzgün kullanıldığında size bazı güzel faydalar sağlayabilen BİR metriktir, ancak yanlış kullanılırsa aslında kötü testlere yol açabilir. Yukarıda belirtilen çok değerli yan etkilerin yanı sıra, yalnızca test edilen sistemin bazı giriş verileri için bu hatta ulaşabildiğini ve asılı veya çökmeden çalışabileceğini gösterir.

Eğer burası mükemmel bir dünya olsaydı, kodun% 100'ü birim testlerle karşılanacaktı. Ancak, bu mükemmel bir dünya DEĞİLDİR, bu sizin için zamanınızın ne olduğu meselesidir. Sonuç olarak, belirli bir yüzdeye daha az odaklanmanızı ve kritik alanlara daha fazla odaklanmanızı öneririm. Kodunuz iyi yazılmışsa (veya en azından makul bir faksı), API'lerin başka bir koda maruz kaldığı birkaç önemli nokta olmalıdır.

Test çabalarınızı bu API'lara odaklayın. API'lerin 1) iyi belgelendiğinden ve 2) belgelere uygun test senaryolarının yazıldığından emin olun. Beklenen sonuçlar dokümanlarla eşleşmiyorsa, kodunuzda, belgelerinizde veya test senaryolarınızda bir hata vardır. Hepsi veteriner hekim için iyidir.

İyi şanslar!

Birçok dükkan testlere değer vermez, bu yüzden en azından sıfırın üstündeyseniz, değerin bir miktar takdiri vardır - bu yüzden tartışmasız sıfır olmayan birçoğu hala sıfır olduğu için kötü değildir.

Net dünyasında insanlar genellikle% 80'i akılcı olarak sunarlar. Ama bunu çözüm seviyesinde söylüyorlar. Proje düzeyinde ölçmeyi tercih ederim: Selenyum vb. Veya manuel testleriniz varsa UI projesi için% 30 iyi olabilir, veri katmanı projesi için% 20 iyi olabilir, ancak iş için% 95 + oldukça başarılı olabilir tamamen gerekli değilse, katman katmanı. Dolayısıyla, genel kapsam% 60 olabilir, ancak kritik iş mantığı çok daha yüksek olabilir.

Bunu da duydum:% 100'ü hedefleyin ve% 80'i vuracaksınız; ancak% 80'i hedeflediğinizde% 40'a ulaşacaksınız.

Alt satır: 80:20 kuralını uygulayın ve uygulamanızın hata sayısının size yol göstermesine izin verin.

Kod kapsamı yalnızca bir metriktir. Kendi başına, çok yanıltıcı olabilir (bkz. Www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Bu nedenle hedefiniz% 100 kod kapsamı elde etmek değil, uygulamanızın ilgili tüm senaryolarını test ettiğinizden emin olmak olmalıdır.

% 85'i, giriş kriterleri için iyi bir başlangıç ​​noktası olacaktır.

Muhtemelen nakliye kriterleri için test edilen alt sistemlerin / bileşenlerin kritikliğine bağlı olarak çeşitli daha yüksek çubuklar seçtim.

Cobertura kullanıyorum ve yüzde ne olursa olsun, cobertura kontrol görevindeki değerleri güncel tutmanızı tavsiye ederim. En azından, totallinerate ve totalbranchrate'i mevcut kapsama alanınızın hemen altına yükseltmeye devam edin, ancak bu değerleri asla düşürmeyin. Ayrıca Ant build fail özelliğini bu göreve bağlayın. Yapı, kapsam eksikliği nedeniyle başarısız olursa, birisinin eklenen kodunu biliyorsunuz, ancak test etmedi. Misal:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Kodumun yeterince test edilmediğini düşündüğümde ve bir sonraki testin ne yapılacağından emin olmadığımda, bir sonraki testin ne yapılacağına karar vermeme yardımcı olmak için kapsam kullanıyorum.

Bir birim testindeki kapsamı artırırsam - bu birim testinin bir şey olduğunu biliyorum.

Bu kapsam dahilinde olmayan,% 50 kapsamındaki veya% 97 kapsamındaki kod için geçerlidir.

Otomatik kabul testleri, muhtemelen diğer entegrasyon testleri ve birim testlerinin bir kombinasyonunu kullanan BDD'yi tercih ederim. Benim için soru, otomatik test paketinin bir bütün olarak hedef kapsamının ne olması gerektiğidir.

Bu bir yana, cevap metodolojinize, dilinize, test ve kapsama araçlarınıza bağlıdır. Ruby veya Python'da TDD yaparken% 100 kapsama alanı sağlamak zor değildir ve bunu yapmaya değer. % 100 kapsamı yönetmek, yüzde 90'lık bir kapsamdan çok daha kolaydır.Yani, kapsama boşluklarını göründükleri gibi doldurmak (ve TDD kuyu kapsama boşlukları nadiren ve genellikle zamanınıza değer) doldurmak, etrafa girmediğiniz kapsama boşluklarının bir listesini yönetmek ve kapsamı kaçırmaktan daha kolaydır. ortaya çıkarılan kodun arka planınız nedeniyle gerilemeler.

Cevap aynı zamanda projenizin geçmişine de bağlıdır. Yukarıdakileri sadece başından beri bu şekilde yönetilen projelerde pratik buldum. Büyük eski projelerin kapsamını büyük ölçüde geliştirdim ve buna değdi, ancak geri dönüp her kapsama boşluğunu doldurmayı hiç pratik bulmadım, çünkü eski test edilmemiş kod bunu doğru bir şekilde yapacak kadar iyi anlaşılmadı ve hızlı bir şekilde.

İyi bir süre birim testi yapıyorsanız, bunun% 95 + 'ya yaklaşmaması için bir neden göremiyorum. Bununla birlikte, en azından, testte yeni olsa bile her zaman% 80 ile çalıştım.

Bu sayı yalnızca projede yazılan kodu içermelidir (çerçeveler, eklentiler vb. Hariç) ve hatta tamamen dış koda yapılan aramalardan yazılan koddan oluşan belirli sınıfları hariç tutabilir. Bu tür bir arama alay edilmeli / inatlanmalıdır.

Genel olarak konuşursak, okuduğum çeşitli mühendislik mükemmelliği uygulama kağıtları, birim testlerde yeni kod için% 80 en iyi getiriyi sağlayan noktadır. % CC'nin üstüne çıkmak, harcanan çaba miktarı için daha az miktarda hata verir. Bu, birçok büyük şirket tarafından kullanılan en iyi uygulamadır.

Ne yazık ki, bu sonuçların çoğu şirketlere aittir, bu yüzden size işaret edebileceğim hiçbir kamu literatürü yoktur.

Kod kapsamı harika, ancak bundan elde ettiğiniz faydalar, elde etme maliyetinden / çabasından ağır bastığı sürece.

Bir süredir% 80 standardında çalışıyoruz, ancak bunu terk etmek ve bunun yerine testimize daha fazla odaklanmak için karar verdik. Karmaşık iş mantığına vb. Konsantre olmak,

Bu karar, kod kapsamını takip etmek ve mevcut birim testlerini sürdürmek için harcadığımız sürenin artması nedeniyle alınmıştır. Kod kapsamımızdan elde ettiğimiz faydanın, bunu başarmak için harcadığımız çabadan daha az olduğu noktaya geldiğimizi hissettik.

Kısa cevap:% 60-80

Uzun cevap: Bence bu tamamen projenizin doğasına bağlı. Tipik olarak her pratik parçayı birim test ederek bir projeye başlarım. Projenin ilk "sürümünde" yaptığınız programlama türüne göre oldukça iyi bir taban yüzdesine sahip olmalısınız. Bu noktada, minimum kod kapsamını "zorunlu kılmaya" başlayabilirsiniz.

Crap4j'e göz atın . Düz kod kapsamından biraz daha karmaşık bir yaklaşım. Kod kapsamı ölçümlerini karmaşıklık ölçümleriyle birleştirir ve ardından şu anda hangi karmaşık kodun test edilmediğini gösterir.

Bu bilmeceye cevabım test edebileceğiniz kodun% 100 satır kapsamına ve test edemediğiniz kodun% 0 satır kapsamına sahip olmaktır.

Python Benim şu anki uygulama iki klasörler halinde benim .py modülleri bölmektir: app1 / ve app2 / ve çalışan birim testleri görsel bu iki klasörlerin kapsama hesaplamak ve ne zaman kontrol edin (ı gerekir app1% 100 kapsama sahip olduğunu bu birgün otomatikleştirmek) ve app2% 0 kapsama alanına sahip.

Bu sayıların standarttan farklı olduğunu / ne zaman bulduğumu tespit edersem ve kodun tasarımını değiştiririm, böylece kapsama alanı standarda uygundur.

Bu, kütüphane kodunun% 100 satır kapsamına ulaşılmasını önerebileceğim anlamına gelir.

Ayrıca bazen orada herhangi bir kodu test edip edemeyeceğimi görmek için app2 / 'yi gözden geçiriyorum ve eğer yapabilirsem app1 /

Şimdi toplam kapsama alanı konusunda fazla endişelenmiyorum, çünkü bu projenin büyüklüğüne bağlı olarak çılgınca değişebilir, ancak genellikle% 70 ila% 90'ın üzerinde gördüm.

Python ile, kapsamı ölçerken uygulamamı otomatik olarak çalıştırabilecek ve duman testini unittest rakamlarıyla birleştirirken umarım% 100'lük bir toplam elde edebilecek bir duman testi tasarlayabilmeliyim.

Kapsamı başka bir perspektiften görüntüleme: Net bir kontrol akışına sahip iyi yazılmış kod, kapsaması en kolay, okunması en kolay ve genellikle en az hatalı koddur. Netlik ve güvenilirlik göz önünde bulundurularak kod yazarak ve kodla paralel birim testleri yazarak en iyi sonuçları IMHO elde edersiniz.

Bence cevap "Ne kadar zamanınız olduğuna bağlı". % 100 elde etmeye çalışıyorum ama sahip olduğum zamana ulaşmazsam karışıklık yapmıyorum.

Birim testleri yazarken, üretim kodu geliştirirken giydiğim şapkaya kıyasla farklı bir şapka takıyorum. Test edilen kodun ne yaptığını ve onu kırabilecek durumların neler olduğunu düşünüyorum.

Genellikle aşağıdaki kriterlere veya kurallara uyarım:

1. Birim Testi, kodlarımın beklenen davranışları hakkında bir belge türü olmalıdır. beklenen çıktı ve istemcilerin yakalamak isteyebileceği istisnalar verildi (Kodumun kullanıcıları ne bilmeli?)

2. Ünite Testinin, henüz düşünmediğim durumları keşfetmeme yardımcı olması gerekir. (Kodumu nasıl stabil ve sağlam hale getirebilirim?)

Bu iki kural% 100 kapsama alanı oluşturmuyorsa, öyle olsun. Ama bir kez, zamanım var, ortaya çıkarılan blokları ve hatları analiz ediyorum ve hala birim testler olmadan test durumları olup olmadığını veya gereksiz kodları ortadan kaldırmak için kodun yeniden düzenlenmesi gerekip gerekmediğini tespit ediyorum.

Bu büyük ölçüde uygulamanıza bağlıdır. Örneğin, bazı uygulamalar çoğunlukla birim test edilemeyen GUI kodundan oluşur.

Böyle bir S / B kuralı olabileceğini sanmıyorum.
Kod, kritik ayrıntılara özellikle dikkat edilerek gözden geçirilmelidir.
Ancak, eğer test edilmemişse, bir hata var!

Kodun kritikliğine bağlı olarak,% 75-% 85 arasında herhangi bir yer iyi bir kuraldır. Gönderim kodu kesinlikle ev hizmetlerinden vb. Daha kapsamlı bir şekilde test edilmelidir.

Bu, uygulama geliştirme yaşam döngünüzün hangi aşamasında olduğunuza bağlı olmalıdır.

Bir süredir geliştirme aşamasındaysanız ve halihazırda çok sayıda uygulanmış kodunuz varsa ve şimdi kod kapsamı hakkında düşünmeniz gerektiğini fark ediyorsanız, mevcut kapsamınızı (varsa) kontrol etmeniz ve ardından bu taban çizgisini kullanmanız gerekir. her sprint için kilometre taşları ayarlayın (veya bir sprint dönemi boyunca ortalama bir artış), bu da son kullanıcı değerini sunmaya devam ederken kod borcunu almak anlamına gelir (en azından benim deneyimime göre, testi artırdıysanız son kullanıcı bir bit umursamıyor yeni özellikler görmedikleri takdirde).

Alan adınıza bağlı olarak% 95 çekim yapmak mantıksız değildir, ancak ortalama olarak% 85 ila% 90'lık ortalama bir duruma bakacağınızı söylemeliyim.

Doğru kod kapsamının en iyi belirtisinin, birim testlerinin düzeltmeye yardımcı olduğu somut sorunların miktarının, oluşturduğunuz birim test kodunun boyutuna uygun olması olduğunu düşünüyorum.

En önemli şeyin zaman içinde kapsama eğiliminin ne olduğunu bilmek ve trenddeki değişikliklerin nedenlerini anlamak olduğunu düşünüyorum. Trenddeki değişiklikleri iyi ya da kötü olarak görüp görmemek, neden analizinize bağlıdır.

Birkaç gün öncesine kadar>% 80'i hedefliyorduk, ancak bir sürü Oluşturulan kod kullandıktan sonra,% yaşını önemsemiyoruz, ancak gözden geçirenin gerekli kapsamı aramasını sağlayın.

Testivus kaydından cevap bağlamının ikinci programcı olması gerektiğini düşünüyorum. Bunu pratik bir bakış açısıyla söyledikten sonra, çabalamak için parametre / hedeflere ihtiyacımız var. Ben bu mimarlık, işlevsellik (kullanıcı hikayeleri) sahip kod analiz ederek bir Agile sürecinde "test edilebilir" düşünün ve sonra bir sayı ile gelip. Telekom alanındaki deneyimlerime dayanarak,% 60 kontrol etmek için iyi bir değer olduğunu söyleyebilirim.