it-swarm-tr.com

Birim testler için makul bir kod kapsamı% nedir (ve neden)?

Birim testler için minimum bir yüzde kod kapsamı zorunlu kılsaydınız, belki bir havuza bağlanma şartı olarak, ne olurdu?

Lütfen cevabınıza nasıl ulaştığınızı açıklayın (çünkü tüm yaptığınız bir rakamı seçseydi, o zaman hepsini kendim yapabilirdim;)

572
sanity

Alberto Savoia'nın bu nesri tam olarak şu soruyu yanıtlar (bu konuda oldukça eğlenceli bir şekilde!):

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

Test Kapsamında Testivus

Bir sabah erken, 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şelenmeyin, sadece bazı iyi testler yazın.”

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

...

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

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

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

Şaşkın görünen programcı cevap verdi:

“Size nasıl söyleyebilirim? Bu, kaç kişiyi beslemeniz gerektiğine, ne kadar aç olduklarına, ne tür başka yemek yediğinize, ne kadar pirinç bulunduğunuza 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 kod kapsamı hakkında aynı soruyu sordu.

“Yüzde seksen ve daha az değil!” Ustayı sert bir sesle cevapladı, yumruklarını masaya vurdu.

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

...

Bu son cevabın ardından genç bir çırak ustaya yaklaştı:

“Büyük usta, bugün size kod kapsamı hakkındaki aynı soruyu üç farklı cevapla cevapladığınızı duydum. Neden?"

Büyük usta sandalyesinden ayağa kalktı:

“Gel, benimle biraz taze çay al ve konuşalım.”

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

“İlk programcı yeni ve teste yeni başlıyor. Şu anda çok fazla kodu var ve sınavları yok. Gidecek çok yolu var; Şu anda kod kapsamına odaklanmak, iç karartıcı ve oldukça işe yaramaz olurdu. Bazı testler yazmaya ve denemeye alışması daha iyi. Daha sonra kapsama konusunda endişelenebilir. ”

“Öte yandan, ikinci programcı hem programlama hem de test etme konusunda oldukça tecrübelidir. Bir tencereye kaç tane pirinç taneleri koymam gerektiğini sorduğumda cevap verdiğimde, gerekli test miktarının bir dizi faktöre bağlı olduğunu fark etmesine yardım ettim ve bu faktörleri benden daha iyi biliyor - sonuçta bu onun kodu . Tek, basit, cevap yoktur ve gerçeği ele alacak ve bununla çalışacak kadar akıllıdır. ”

Genç çırak, “anlıyorum” dedi, ancak tek bir basit cevap yoksa neden üçüncü programcıya “Yüzde seksen ve daha az değil” cevabını verdiniz? ”Dedi.

Büyük usta o kadar sert ve yüksek sesle güldü ki göbeği, yeşil çaydan daha çok içtiğini kanıtladı, aşağı ve yukarı fırladı.

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

Genç çırak ve büyük usta, çaylarını tefekkür sessizliğinde içmeyi bitirdi.

1309
Jon Limjap

Hedefiniz% 100 kapsama (tüm özellikleri% 100 test etmek yerine) ise Kod Kapsamı yanıltıcı bir ölçümdür.

  • Tüm çizgilere bir kez vurarak% 100 kazanabilirsiniz. Bununla birlikte, bu satırların vurulduğu belirli bir diziyi (mantıksal yol) sınamaya devam edemezsiniz.
  • % 100 elde edemezsiniz, ancak yine de tüm% 80/freq kullanılmış kod yollarınızı test ettiniz. Her atma ExceptionTypeX'i veya koyduğunuz benzer savunma programlama korumasını test eden testlere sahip olmak, 'olması gereken bir' olmamış 'olması gereken'

Bu yüzden, kendinize veya geliştiricilerinize eksiksiz davranıp, kodları dahilindeki her yolu örtbas etmesi için güvenin. Pragmatik olun ve büyülü% 100 kapsama alanını takip etmeyin. Kodunuzu TDD olarak girmişseniz, bonus olarak% 90 + kapsamı almanız gerekir. Kaçırdığınız kod parçalarını vurgulamak için kod kapsamını kullanın (yalnızca TDD'ye yazdıysanız, olmamalıdır .. yalnızca bir test geçişi yapmak için kod yazdığınızdan emin olun. Ortak testi olmadan kod olamaz).

82
Gishu

Kod kapsamı harika, ancak işlevsellik kapsamı daha da iyi. Yazdığım her satırı örtmeye inanmıyorum. Ancak, sağlamak istediğim tüm işlevselliklerin% 100 test kapsamasını yazmaya inanıyorum (kendimle birlikte geldiğim ve toplantılar sırasında konuşulmayan ekstra harika özellikler için bile).

Testlerde yer almayan bir kodum olup olmaması umrumda değil, ancak kodumu yeniden gözden geçirip farklı bir davranışa sahip olmamı umursardım. Bu nedenle,% 100 işlevsellik kapsamı tek hedefim.

55
tofi9

Kabul edilen cevap iyi bir noktaya değindi - her proje için standart olarak anlamlı olacak tek bir sayı yok. Sadece böyle bir standarda ihtiyaç duymayan projeler var. Kabul edilen cevabın yetersiz kaldığı yer benim görüşüme göre, verilen bir proje için bu kararı nasıl verebileceğini açıklamaktır.

Bunu yaparken bir göz atacağım. Test mühendisliği konusunda uzman değilim ve daha bilinçli bir cevap görmekten mutlu olurum.

Kod kapsamı gereksinimleri ne zaman belirlenir?

Birincisi, neden böyle bir standardı en baştan uygulamak istiyorsunuz? Genel olarak, işleminize ampirik bir güven vermek istediğinizde. "Ampirik güven" ile ne kastediyorum? Eh, asıl amaç doğruluk. Çoğu yazılım için, bunu tüm girdilerde bilemeyiz, bu yüzden bu kodun iyi test edilmiş olduğunu söylemeye razıyız. Bu daha iyi bilinir, ancak yine de öznel bir standarttır: Sizinle tanışıp tanışmadığınızı tartışmaya her zaman açık olacaktır. Bu tartışmalar faydalıdır ve gerçekleşmesi gerekir, fakat aynı zamanda belirsizlik de ortaya çıkar.

Kod kapsamı objektif bir ölçümdür: Kapsam raporunuzu gördüğünüzde, standartların karşılanıp karşılanmadığına dair bir belirsizlik yoktur. Doğruluk kanıtlıyor mu? Hiç de değil, ama kodun ne kadar iyi test edildiğiyle açık bir ilişkisi var, bu da doğruluktaki güveni arttırmanın en iyi yoludur. Kod kapsamı, önemsediğimiz ölçülemez niteliklerin ölçülebilir bir yaklaşımıdır.

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

  • Paydaşları memnun etmek için. Pek çok projede, yazılımın günlük gelişiminde yer almayan yazılım kalitesine ilgisi olan çeşitli aktörler vardır (yöneticiler, teknik ipuçları vb.). (“Gerçekten ihtiyacımız olan tüm testleri yazacağız” demek, ikna edici değil: ya tamamen güvenmeleri ya da devam eden yakın bir gözetim ile doğrulamaları gerekiyor (bunu yapacak teknik anlayışa sahip olduklarını varsayarak). Gerçek hedeflere makul bir şekilde nasıl yaklaştıklarını açıklamak daha iyidir.
  • Takım davranışını normalleştirmek için. Paydaşlar bir yana, birden fazla kişinin kod ve testler yazdığı bir ekip üzerinde çalışıyorsanız, "iyi test edilmiş" olarak nitelendirilen şeyin belirsizliğine yer vardır. Tüm meslektaşlarınız hangi test seviyesinin yeterince iyi olduğu konusunda aynı fikirde mi? Muhtemelen değil. Bunu nasıl uzlaştırırsın? Kabul edebileceğiniz bir ölçüm bulun ve makul bir yaklaşım olarak kabul edin. Bu özellikle (ancak münhasıran değil), örneğin liderlerin genç geliştiriciler üzerinde doğrudan gözetimsiz olabileceği büyük takımlarda faydalıdır. Güven ağları da önemlidir, ancak objektif ö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ş siz olsanız bile, yazılım için belirli özelliklere sahip olabilirsiniz. Yazılımın ne kadar iyi test edildiğine (devam eden) ne kadar sınava yönelik öznel değerlendirmeler yapmak yerine, kod kapsamını makul bir yaklaşım olarak kullanabilir ve makinelerin sizin için ölçmesine izin verebilirsiniz.

Hangi metrikleri kullanmalı

Kod kapsamı tek bir ölçüm değildir; kapsamı ölçmenin birkaç farklı yolu vardır. Hangisini standartlaştıracağınızla, standardı karşılamak için ne kullandığınıza bağlıdır.

Standartları belirlemek için bunları ne zaman kullanabileceğinize örnek olarak iki ortak ölçüm kullanacağım:

  • İfade kapsamı: Test sırasında ifadelerin yüzde kaçı yapıldı? Kodunuzun fiziksel kapsam 'ını anlamak için kullanışlıdır: Kodumun ne kadarını gerçekten test ettim?
    • Bu tür bir kapsama, daha zayıf bir doğruluk argümanını destekler, ancak elde edilmesi de daha kolaydır. İşlerin sınanmasını sağlamak için yalnızca kod kapsamını kullanıyorsanız , (bunun ötesinde test kalitesinin bir göstergesi olarak değil), açıklama kapsamı muhtemelen yeterlidir .
  • Branş kapsamı: Dallanma mantığı olduğunda (örneğin, bir if), her iki dal da değerlendirildi mi? Bu, kodunuzun mantıksal kapsamı 'ını daha iyi anlar: Kodumun kaç olası yolu sınamış olabilir?
    • Bu tür bir kapsama, bir programın kapsamlı bir girdiler dizisinde test edildiğinin çok daha iyi bir göstergesidir. Kod kapsamını, doğruluk konusunda güven duymanız için en iyi ampirik yaklaşımınız olarak kullanıyorsanız, branş kapsamını veya benzerlerini temel alan standartlar belirlemelisiniz.

Diğer birçok ölçüm vardır (satır kapsamı ifadenin kapsamına benzer, ancak çok satırlı ifadeler için farklı sayısal sonuçlar verir; örneğin, şartlı kapsam ve yol kapsamı branş kapsamına benzer, ancak bunun olası izinlerinin daha ayrıntılı bir görünümünü yansıtır. karşılaşabileceğiniz programın yürütülmesi.)

Hangi yüzde gerekli

Sonunda, asıl soruya dönersek: Kod kapsamı standartlarını belirlerseniz, bu numara ne olmalıdır?

Umarım bu noktada başlayacağımız bir yaklaşımdan bahsettiğimiz açıktır, bu yüzden seçtiğimiz herhangi bir sayı doğal olarak yaklaşık olacaktır.

Birinin seçebileceği bazı numaralar:

  • % 1. Bunu seçebilirsiniz çünkü her şeyin test edildiğinden emin olmak istersiniz. Bu, size test kalitesiyle ilgili herhangi bir fikir vermez, ancak bazı kalite testlerinin her bir ifadeye (veya dal, vb.) Dokunduğunu söyler. Yine, bu güven derecesine geri döner: Kapsamınız% 100'ün altındaysa , biliyorsunuz kodunuzun bazı alt kümeleri denenmemiş.
    • Bazıları bunun aptalca olduğunu iddia edebilir ve yalnızca kodunuzun gerçekten önemli olan kısımlarını test etmeniz gerekir. Ayrıca, yalnızca kodunuzun gerçekten önemli olan kısımlarını korumanız gerektiğini savunuyorum. Kod kapsamı, test edilmemiş kodu da kaldırarak iyileştirilebilir.
  • % 99 (veya% 95, yüksek doksanlı yıllardaki diğer sayılar.) Güven seviyesini iletmek istediğiniz durumlarda uygun benzer % 100’e kadar, ancak ara sıra test edilmesi zor olan kod köşesi için endişelenmeyin.
  • % 8. Bu sayıyı birkaç kez kullanımda gördüm ve nereden kaynaklandığını tam olarak bilmiyorum. Ben 80-20 kuralının tuhaf bir şekilde yanlış kullanımı olabileceğini düşünüyorum; genellikle buradaki amaç, kodunuzun çoğunun test edildiğini göstermektir. (Evet,% 51 aynı zamanda "en çok" olur, ancak% 80 çoğu insanın en çok ne demek istediğini yansıtır .) Bu orta için uygundur “iyi test edilmiş” in yüksek öncelikli olmadığı (düşük değerli testler için çaba harcamak istemezsiniz) değil, yine de bazı standartların uygulanmasını istediğiniz bir öncelik yeterlidir.

Uygulamada% 80'in altındaki rakamları görmedim ve birinin onları koyacağı bir durumu hayal etmekte zorlanıyorum. Bu standartların rolü doğrulukta güveni arttırmaktır ve% 80'in altındaki sayılar özellikle güven verici değildir. (Evet, bu özneldir, ancak yine de, standardı belirlediğinizde öznel seçimi bir kez yapmak ve ardından ileriye dönük objektif bir ölçüm kullanmaktır.)

Diğer notlar

Yukarıdakiler, doğruluğun amaç olduğunu varsaymaktadır. Kod kapsamı sadece bilgidir; diğer hedeflerle ilgili olabilir. Örneğin, sürdürülebilirlik konusunda endişeleriniz varsa, muhtemelen kod kapsamı ile ölçülebilen (bazı modalarda) test edilebilirlik ile gösterilebilecek gevşek kavrama ile ilgileniyorsunuzdur. Bu nedenle, kod kapsama standardınız "bakım" kalitesine de yaklaşmak için deneysel bir temel sağlar.

51
killscreen

En sevdiğim kod kapsamı yıldız işaretiyle% 100'dür. Yıldız işareti, bazı satırları "sayılmayan satırlar" olarak işaretlememe izin veren araçları kullanmayı tercih ettiğim için geliyor. "Sayılan" satırların% 100'ünü kaplamış olsaydım, bittim.

Temel süreç:

  1. Testlerimi, düşünebildiğim tüm işlevsellik ve Edge vakalarını uygulamak için yazıyorum (genellikle belgelerden çalışıyorum).
  2. Kod kapsamı araçlarını çalıştırıyorum
  3. Kapsamsız veya ulaşılamadığını düşündüğüm herhangi bir çizgiyi veya yolu inceliyorum (savunma programlaması nedeniyle)
  4. Eksik hatları kapsayacak şekilde yeni testler yazıyorum ve bu Edge durumlarından söz edilmezse belgeleri geliştiriyorum.

Bu şekilde eğer ben ve ortak çalışanlarım yeni kod ekler veya gelecekteki testleri değiştirirsek, önemli bir şeyi kaçırdığımızı bize söyleyen parlak bir çizgi var - kapsama alanı% 100'ün altına düştü. Bununla birlikte, farklı test öncelikleriyle başa çıkma esnekliği de sağlar.

23
Eponymous

Test kapsamı hakkında paylaşmak istediğim başka bir anectode istiyorum.

Twitter üzerinden şunu belirttiğim gibi çok büyük bir projemiz var, 700 birim testiyle yalnızca% 20 kod kapsamı var .

Scott Hanselman ile yanıtladı bilgelik sözleri :

SAĞ% 20 mi? Kullanıcılarınızın en çok vurdukları kodu temsil eden% 20 mi? 50 test daha ekleyebilir ve sadece% 2 ekleyebilirsiniz.

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

19
Jon Limjap

Ünite testlerinin baştan beri gelişimi yönlendirdiği iyi tasarlanmış bir sistem için% 85'in oldukça düşük bir sayı olduğunu söyleyebilirim. Test edilebilir olarak tasarlanan küçük sınıfların bundan daha iyi ele alınması zor olmamalıdır.

Bu soruyu şu şekilde reddetmek kolaydır:

  • Kapalı satırlar test edilmiş mantığa eşit değildir ve kişi yüzde olarak fazla okumamalıdır.

Doğru, ama kod kapsamı hakkında yapılması gereken bazı önemli noktalar var. Tecrübelerime göre, bu ölçüm doğru kullanıldığında aslında oldukça kullanışlıdır. Bunu söylediğimde, tüm sistemleri görmedim ve kod kapsama analizinin gerçek bir değer katabileceğini görmenin zor olduğu tonlar olduğundan eminim. Kod çok farklı görünebilir ve mevcut test çerçevesinin kapsamı değişebilir.

Ayrıca, mantığım esas olarak oldukça kısa test geri bildirim döngüleri ile ilgilidir. Geliştirdiğim ürün için en kısa geri besleme döngüsü oldukça esnektir ve sınıf testlerinden süreçler arası sinyalleşmeye kadar her şeyi kapsar. Teslim edilebilir bir alt ürünün test edilmesi tipik olarak 5 dakika sürer ve bu kadar kısa bir geri besleme döngüsü için, depodaki işlemleri reddetmek veya kabul etmek için test sonuçlarını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üzdesine sahip olmamalısınız. Bunu yapmak size gerçek faydaları sağlamaz. Kod kapsam analizi bence. Bunun yerine, aşağıdaki ölçümleri tanımlayın:

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

Yeni kod yalnızca LWM'nin üzerine çıkmazsak ve HWM'nin altına düşmezsek eklenebilir. Başka bir deyişle, kod kapsamı azalmasına izin verilmez ve yeni kodun ele alınması gerekir. Yapmam gerekip gerekmediğine dikkat edin (aşağıda açıklanmıştır).

Ancak bu, artık kullanmadığınız eski iyi test edilmiş çöpleri temizlemenin imkansız olduğu anlamına gelmiyor mu? Evet, bu yüzden bu konularda pragmatik olmalısın. Kuralların çiğnenmesi gereken durumlar vardır, ancak tipik günlük entegrasyonunuz için bu ölçümlerin oldukça yararlı olduğunu deneyimliyorum. Aşağıdaki iki sonucu veriyorlar.

  • Test edilebilir kod yükseltildi. Yeni kod eklerken, kodu test edilebilir hale getirmek için gerçekten çaba sarf etmeniz gerekir, çünkü hepsini test durumlarınızla birlikte denemeniz ve karşılamanız gerekir. Test edilebilir kod genellikle iyi bir şeydir.

  • Eski kod için test kapsamı zamanla artmaktadır. Yeni bir kod eklerken ve bir test senaryosuyla kapsayamıyorken, LWM kuralını aşmak yerine bazı eski kodları gizlemeye çalışabilirsiniz. Bu bazen gerekli hile yapmak, en azından, eski kuralların kapsamının zaman içinde artacağı ve bu kuralların görünüşte sıkı bir şekilde uygulanmasının pratikte pragmatik olmasına neden olacağı yönünde olumlu bir etki yaratmaktadır.

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

Ayrıca kod kapsamı ölçümünün iki genel avantajından da 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 problemler (arındırıcı aile gibi araçlar tarafından, http://www-03.ibm.com/software/products/en/rational-purify-family ) başlatılmamış bellek okumaları (UMR), bellek sızıntıları, vb. Bu sorunlar, yalnızca kod yürütülen bir test durumu kapsamındaysa bulunabilir. Bir test durumunda ele alınması en zor olan kod genellikle sistemdeki anormal durumlardır, ancak sistemin nezaketsiz bir şekilde çalışmasını istiyorsanız (ör. Çarpışma yerine hata izi), anormal durumları kapatmak için biraz çaba sarf etmek isteyebilirsiniz. dinamik kod analizinde de. Sadece biraz şanssızlık varken, bir UMR segfault veya daha kötü duruma gelebilir.

  • İnsanlar yeni kod için% 100 koruma konusunda gurur duyuyorlar ve insanlar diğer uygulama problemleriyle aynı tutkuyla test sorunlarını tartıştılar. Bu fonksiyon daha iyi bir şekilde nasıl yazılabilir? Bu anormal olayı örtbas etmeye çalışmak nasıl?.

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

  • Çok sayıda geliştiricinin katıldığı büyük bir projede, herkes kesinlikle bir test dehası olmayacak. Bazı insanlar, kod kapsamı metriğini, kodun test edildiğinin kanıtı olarak kullanma eğilimindedir ve bu, diğerlerinin çoğunda belirtildiği gibi, gerçeklerden çok uzaktır. bu sorunun cevapları. Doğru kullanıldığında size güzel faydalar sağlayabilecek BİR metriktir, ancak yanlış kullanılırsa, aslında kötü testlere yol açabilir. Yukarıda belirtilen çok kıymetli yan etkilerin yanı sıra, sadece kapalı bir çizgide test edilen sistemin bazı girdi verileri için bu çizgiye ulaşabileceğini ve askıda kalmadan veya çökmeden çalışabileceğini göstermektedir.
8
Martin G

Eğer burası kusursuz bir dünya olsaydı, kodun% 100'ü birim testleriyle karşılanırdı. Ancak, bu mükemmel bir dünya olmadığı için, vaktinin ne olduğu meselesi. Sonuç olarak, belirli bir yüzdeye daha az odaklanmanızı ve daha kritik bölgelere odaklanmanızı öneririm. Kodunuz iyi yazılmışsa (veya en azından makul bir faks faktörü ise), API'lerin başka bir koda maruz kaldığı birkaç kilit nokta olmalıdır.

Test çalışmalarınızı bu API'lara odaklayın. API'lerin 1) iyi belgelendiğinden ve 2) belgelere uygun sınama durumları olduğundan emin olun. Beklenen sonuçlar dokümanlar ile eşleşmiyorsa, kodunuzda, belgelerinizde veya test durumlarınızda bir hata vardır. Hepsi dışarı çıkmak için iyi.

İyi şanslar!

7
64BitBob

% 85'i check-in kriterleri için iyi bir başlangıç ​​olabilir.

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

5
stephbu

Pek çok dükkan testlere değer vermez, bu yüzden en azından sıfırın üzerindeyseniz değerin bir değeri vardır - bu yüzden kesinlikle sıfır olmayanların çoğu hala sıfır olduğu kadar kötü değildir.

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

Bunu da duydum:% 100 hedeflediğinizde% 80'e varacaksınız; ancak% 80’e aday olun,% 40’a ulaşacaksınız.

Alt satır: 80:20 kuralını uygulayın ve uygulamanızın hata sayısının sizi yönlendirmesine izin verin.

5
Greg Trevellick

Cobertura kullanıyorum ve yüzde ne olursa olsun, cobertura-check görevindeki değerleri güncel tutmanızı tavsiye ederim. En azından, mevcut kapsama alanınızın hemen altına getirmek için totallinerat ve totalbranchrate yetiştirmeye devam edin, ancak asla bu değerleri azaltın. Ayrıca Ant yapı hatası özelliğini bu göreve bağlayın. Derleme kapsama eksikliği nedeniyle başarısız olursa, birisinin eklenmiş kodunu biliyorsunuz ancak test etmediniz. Örnek:

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

Kodumun yeterince test edilmediğini ve bir sonraki testte ne yapacağımdan emin olamadığımı düşündüğümde, bir sonraki testte karar vermeme yardımcı olması için kapsamı kullanıyorum.

Birim testinde kapsamı arttırırsam - bu birim testinin bir değeri olduğunu biliyorum.

Bu, kodsuz,% 50 kapalı veya% 97 kapalı kod için geçerlidir.

4
brickner

Kod kapsamı sadece başka bir ölçümdür. Kendi içinde çok yanıltıcı olabilir (bakınız www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Bu nedenle amacınız% 100 kod kapsamı elde etmek değil, uygulamanızın tüm ilgili senaryolarını test ettiğinizden emin olmak olmalıdır.

4
klementtt

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

Bu bir yana, cevap, metodolojinize, dile ve test ve kapsam araçlarına bağlıdır. Ruby veya Python içinde TDD yaparken,% 100 kapsama alanını korumak zor değildir ve bunu yapmaya değer. % 90'lık kapsama alanından% 100'lük kapsama alanını% 100 yönetmek daha kolaydır. Yani, kapsama boşluklarını göründükleri gibi doldurmak çok daha kolaydır (ve TDD iyi kapsama boşlukları nadir görülür ve genellikle zaman ayırmaya değer ) daha önce almadığınız kapsama boşluklarının bir listesini yönetmek ve sürekli açığa çıkmış kod geçmişinizden dolayı kapsama regresyonlarını kaçırmamak.

Cevap aynı zamanda projenizin geçmişine de bağlıdır. Yukarıdakileri baştan beri bu şekilde yönetilen projelerde pratik yapmak için buldum. Büyük eski projelerin kapsamını büyük ölçüde geliştirdim ve bunu yapmaya değdi, ancak eski denenmemiş kodun bunu doğru bir şekilde yapması için yeterince anlaşılmadığı için geri dönüp her kapsama boşluğunu doldurma konusunda pratik olmamıştım ve hızlı bir şekilde.

4
Dave Schweisguth

Genel olarak konuşursak, birkaç mühendislik mükemmeliyetinden okuduğum en iyi uygulama kağıtları, birim testlerinde yeni kod için% 80 en iyi getiriyi sağlayan nokta. % CC’nin üzerine çıkıldığında, harcanan çaba miktarı için daha düşük 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 şirketlerin içindedir, bu nedenle sizi işaret edebileceğim hiçbir kamu literatürü yoktur.

3
user17222

Kod kapsamı harikadır, ancak yalnızca bundan aldığınız faydalar, elde etmenin maliyetinden/çabalarından ağır basarsa.

Bir süredir% 80 standartlarında çalışıyoruz, ancak bunu bırakma kararını verdik ve testlerimize daha fazla odaklanmaya karar verdik. Karmaşık iş mantığına vb. Odaklanmak,

Bu karar, kod kapsamını kovalamak ve mevcut birim testlerini sürdürmek için harcadığımız zamanın artması nedeniyle alındı. Kod kapsamımızdan elde ettiğimiz kazancın, bunu başarmak için harcadığımız çabadan daha az olduğunu düşündüğümüz noktaya geldiğimizi hissettik.

3
Simon Keep

Uygun bir süre boyunca birim test yapıyorsanız,% 95 + seviyesine yaklaşmaması için hiçbir neden göremiyorum. Ancak, en azından, testlerde yeniyken bile her zaman% 80 ile çalıştım.

Bu numara yalnızca projede yazılı olan kodları içermelidir (çerçeveler, eklentiler hariç, vb.) Ve hatta tamamen dış koda yapılan çağrılardan yazılan koddan oluşan bazı sınıfları hariç tutabilir. Bu tür bir arama yapılmalı/engellenmelidir.

3
Tony Pitale

Bu bilime cevabım, test edebileceğiniz kodun% 100'ünü, test edemediğiniz kodun% 0'ını içerir.

Python'daki şu anki çalışmam. .Py modüllerimi iki klasöre bölmektir: app1/ve app2/ve birim testleri çalıştırırken bu iki klasörün kapsamını hesaplar ve görsel olarak kontrol edin (I gerekir) bunu bir gün otomatikleştirin) app1'in% 100 kapsama alanına sahip olduğu ve app2'nin% 0 kapsama alanına sahip olduğu.

Eğer/bu sayıların standarttan farklı olduğunu tespit edersem, kodun tasarımını araştırırım ve değiştirir, böylece kapsam standartlara uygun olur.

Bu, kütüphane kodunun% 100'ünü kapsam dahil etmeyi önerebileceğim anlamına geliyor.

Ayrıca arada sırada herhangi bir kodu test edip edemediğimi görmek için app2/'yi gözden geçiririm ve yapabilirsem app1 /' e taşıyabilirim.

Şimdi toplam kapsama alanı hakkında fazla endişelenmiyorum çünkü proje büyüklüğüne göre çılgınca değişebiliyor, ancak genel olarak% 70 -% 90'ın üzerinde gördüm.

Python ile kapsama alanı ölçülürken uygulamamı otomatik olarak çalıştırabilecek bir duman testi tasarlayabilmeliyim ve duman testini en ufak rakamlarla birleştirirken umarım% 100'lük bir kazanç elde etmeliyim.

2
quamrana

Çıkış Crap4j . Düz kod kapsamından biraz daha karmaşık bir yaklaşım. Kod kapsamı ölçümlerini karmaşıklık ölçümleriyle birleştirir ve daha sonra hangi karmaşık kodların test edilmediğini gösterir.

2
Don Kirkby

Benim düşünceme göre, cevap "Ne kadar zamanın olduğuna bağlı". % 100'e ulaşmaya çalışıyorum, ancak zamanımın gelmediği takdirde telaşlanmıyorum.

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

Genellikle aşağıdaki kriterleri ya da kuralları izlerim:

  1. Birim Testinin kodlarımın beklenen davranışının ne olduğuna dair bir dokümantasyon biçimi olması gerektiği, yani. belirli bir girdi verilen beklenen çıktı ve müşterilerin yakalamak isteyebilecekleri istisnalar (Kodumun kullanıcıları ne bilmeli?)

  2. Birim Testinin, henüz düşünmemiş olabileceğim şeyleri keşfetmeme yardımcı olması. (Kodumu nasıl kararlı ve sağlam hale getirebilirim?)

Eğer bu iki kural% 100 kapsam oluşturmuyorsa, öyle olsun. Ancak bir kez vaktim var, ele geçen blokları ve çizgileri analiz ediyorum ve birim testleri olmadan hala test durumları olup olmadığını ya da gereksiz kodları ortadan kaldırmak için kodun yeniden yapılandırılması gerekip gerekmediğini tespit ediyorum.

2
Mark Menchavez

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

1
Thomas

Böyle bir B/W kuralı olabileceğini sanmıyorum.
Kod, kritik ayrıntılara özellikle dikkat edilerek gözden geçirilmelidir.
Ancak, test edilmediyse, bir hata yaptı!

1
Nescio

Kısa cevap:% 60-80

Uzun cevap: Tamamen projenizin doğasına bağlı olduğunu düşünüyorum. Genellikle her pratik parçayı test ederek bir projeye başlarım. Projenin ilk “sürümüne” göre, yaptığınız programlama türüne bağlı olarak oldukça iyi bir taban yüzdesine sahip olmalısınız. Bu noktada, minimum kod kapsamı "zorlamaya" başlayabilirsiniz.

1
user11087

Kodun önemine bağlı olarak,% 75 -% 85'ten herhangi bir yer, iyi bir kuraldır. Nakliye kodu kesinlikle ev hizmetlerinde, vb. Daha ayrıntılı bir şekilde test edilmelidir.

1
William Keller

Bu, uygulama geliştirme yaşam sürenizin hangi aşamasında olduğunuza bağlı olmalıdır.

Bir süredir geliştirme aşamasındaysanız ve bir çok uygulanmış kodunuz varsa ve şu anda kod kapsamı hakkında düşünmeniz gerektiğini anlıyorsanız, geçerli kapsamınızı kontrol etmeniz (varsa) ve bu temel çizgiyi kullanmanız gerekir. her bir sprint (veya bir sprint periyodu boyunca ortalama bir artış) için kilometre taşları belirledi; bu, son kullanıcı değeri sunmaya devam ederken kod borcunu almak anlamına geliyor (en azından benim deneyimlerime göre, son kullanıcı testi arttırırsanız bir bit umursamıyor) kapsama yeni özellikler görmüyorsa).

Etki alanınıza bağlı olarak% 95 oranında çekim yapmak mantıksız değildir, ancak ortalama olarak% 85 ila% 90 arasında bir durumda olacağınızı söylemek zorundayım.

1
codeLes

Doğru kod kapsamının en iyi belirtisinin birim testlerinin düzeltilmesine yardımcı olduğu somut sorunların miktarının, yarattığınız birim test kodunun boyutuna makul bir şekilde denk geldiğini düşünüyorum.

1
dimarzionist

En önemlisi, zaman içinde kapsama eğiliminin ne olduğunu bilmek ve trenddeki değişikliklerin nedenlerini anlamak olduğunu düşünüyorum. Eğilimdeki değişiklikleri iyi ya da kötü olarak görüp görmemeniz sebebi analizinize bağlı olacaktır.

1
Rob Scott

Testivus kayıtlarından cevap içeriğinin ikinci programcı olması gerektiğini düşünüyorum. Bunu pratik bir bakış açısıyla söyledikten sonra, çaba sarf etmek için parametre/hedeflere ihtiyacımız var. Bunun, çevik bir süreçte mimariye, işlevselliğe (kullanıcı hikayelerine) sahip olduğumuz kodu analiz ederek "test edilebileceğini" düşünüyorum ve ardından bir sayı buldum. Telekom alanındaki tecrübelerime dayanarak şunu söyleyebilirim:% 60'ı kontrol etmek için iyi bir değer.

0
D Lovece

Birkaç gün öncesine kadar>% 80'i hedefliyorduk, ancak çok sayıda Oluşturulan kod kullandıktan sonra,% yaşını umursamıyoruz, ancak gözden geçirenin gerekli olanı aramasını istiyor.

0
reva