Artık insanların bu soruyu yinelediğini veya birçok kez sorduğunu biliyorum, bu durumda sorumun cevabıyla ilgili soruların bağlantısını takdir ediyorum.
Son zamanlarda bazı insanlarla kod kapsamı konusunda anlaşamadım. % 100 kapsamın kaliteli testler ve dolayısıyla kaliteli kod anlamına gelmediği iddiasına dayanarak ekibimizin kod kapsamına tamamen bakmasını isteyen bir grup insanım var.
Kod Kapsamı'nın neyin test edilmediğini bana söylediği ve bu alanlara odaklanmamıza yardımcı olduğu iddiasını satarak geri itebildim.
(Yukarıdakiler, buna benzer diğer SO sorularında benzer bir şekilde tartışılmıştır - /programming/695811/pitfalls-of-code-coverage )
Bu milletlerin argümanı - ekip hızlı bir şekilde düşük kalite testleri oluşturarak tepki verecek ve böylece önemli bir kalite eklemeden zaman kaybedecektir.
Onların bakış açılarını anlasam da, daha fazla kapsam ölçütüyle ilgilenen daha sağlam araçlar / çerçeveler tanıtarak kod kapsamı için daha sağlam bir durum oluşturmanın bir yolunu arıyorum (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc).
Aradığım şey , bu kod kapsamı araçlarının ve uygulamalarının / süreçlerinin bir araya getirilmesi için öneri olup, önerim hakkında rahat hissederken bu tür argümanlara karşı koymamda bana yardımcı olabilir.
Ayrıca, böyle bir argümana nasıl karşı çıkacağınıza dair deneyiminize / bilginize dayanan eşlik eden yorumları / önerileri de memnuniyetle karşılarım, çünkü öznel olsa da, kod kapsamı ekibimin kod kalitesi ve test değerinin daha bilinçli olmasına yardımcı oldu.
Düzenleme: Tipik kod kapsama zayıflık benim anlayış hakkında herhangi bir karışıklığı azaltmak için, ben (veya kod satırları yürütülen) araçları (bol var) atıfta değil işaret etmek istiyorum Statement Coverage. Aslında burada yanlış olan her şey hakkında iyi bir makale: http://www.bullseye.com/statementCoverage.html
Ben sadece ifade veya satır kapsama daha fazlasını, birden fazla kapsama kriterleri ve seviyeleri daha fazla arıyordu.
Bkz. Http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
Fikir şu ki, bir araç bize kapsama alanımızı birden fazla kritere göre söyleyebilirse, bu test kalitesinin makul bir otomatik değerlendirmesi haline gelir. Hiçbir şekilde hat kapsamının iyi bir değerlendirme olduğunu söylemeye çalışmıyorum. Aslında sorumun öncüsü bu.
Düzenleme:
Tamam, belki biraz fazla dramatik tahmin, ama nokta olsun. Sorun genel olarak süreçleri / politikaları tüm ekipler arasında homojen / tutarlı bir şekilde belirlemekle ilgilidir. Ve korku, testlerin kalitesini nasıl sağladığınız, herhangi bir önlem almadan nasıl garantili zaman ayırdığınız konusunda genel bir korkudur. Bu nedenle, uygun süreçlerle ve doğru araçlarla desteklendiğinde, zamanın boşa harcanan süreçlerde harcanan güç olmadığını bilerek kod kalitesini artırmamıza izin verecek ölçülebilir bir özelliğe sahip olmayı seviyorum.
EDIT: Şimdiye kadar cevaplardan ne var:
- Kod incelemeleri, testlerin kalitesini sağlamak için testleri kapsamalıdır
- Önce Test stratejisi, kapsamı% artırmak için yazılmış olan testlerden kaçınmaya yardımcı olur
- Sadece İfade / Satır dışındaki test kriterlerini kapsayan alternatif araçları keşfetmek
- Kapsanan kodun / bulunan hataların analizi, kapsamın önemini anlamaya ve daha iyi bir durum ortaya çıkarmaya yardımcı olacaktır.
- En önemlisi, doğru şeyi yapmak ve inançları için savaşmak için Ekibin girdisine güvenmek
- Kapsanan Bloklar / test sayısı - Tartışılabilir ancak bir miktar değer tutar
Şimdiye kadarki harika cevaplar için teşekkürler. Onları gerçekten takdir ediyorum. Bu iş parçacığı, saatlerce süren güçlerle beyin fırtınasından daha iyidir.