Ünite testine ne kadar zaman harcıyorsunuz?

Çalıştığım bir şirkette yöneticiler, birim testleriyle kod kapsamının% 99 veya daha fazla olması konusunda ısrar ettiler. Bu koddan daha fazla test yazmaya neden oldu. Tam anlamıyla 3 gün sürdü, bu da uygulaması bir gün süren tek bir sınıf için testler yazmaktı.

Sonuç olarak, TDD, test araçları, uygulamalar vb. Hakkında çok şey öğrendim.

Daha sonra çalıştığım şirkette birim testleri bilinmeyen bir şeydi. Daha önce birinin duyduğu bir şeydi. Onları birim sınama kavramıyla tanıştırmak için çaba sarf ettim ama etkisiz.

Şimdi, bir serbest meslek sahibi olarak merak ediyorum - birim testine gerçekten ne kadar zaman harcanması gerekiyor? Çoğunlukla iPhone / Android geliştiricisi olan kodun hangi bölümleri testlerde ele alınmalıdır?

Gerekli olan birim testinin miktarı birkaç faktöre bağlıdır:

• Ürün Boyutu (Proje ne kadar büyükse, en azından bazı birim testlerine dahil etme ihtiyacı o kadar büyük)
• İstenilen Kalite Seviyesi (Yazılımı hızlı bir şekilde bir araya getiriyorsanız, olabildiğince hızlı olması gerekiyor ve bazı küçük hatalar kabul edilebilirse, birim testi gibi bazı testleri atlamak zorunda kalabilirsiniz)
• Ürün Türü (UI'ler birim testine tabi tutulabilir, ancak bazen bir projenin ağır GUI bölümlerinde birim testini atlamak ve bunun yerine manuel olarak test etmek daha kolaydır)
• Kodlama Yeteneğiniz / Tarihçeniz (Normalde ne tür hatalar oluşturuyorsunuz? Bunlar normalde Ünite Testi'nin yakaladığı şeyler mi yoksa başka bir test türü normalde bulduğu şeyler mi? Bunu bilmek sizi daha fazla veya daha az ünite testi yapmaya zorlayabilir)

Ürün grubumuzda birim testlerinden% 50-70 kod kapsamını ve birim testlerinden ve test otomasyonundan% 90 + kapsamayı hedefliyoruz. Yazma birimi testlerine bütçelenen tipik süre, 3-4 gün aşağı kodlama gerektiren her özellik için yaklaşık 1 gündür. Ancak bu birçok faktöre bağlı olarak değişebilir.

% 99 kod kapsamı harika. Birim testleri harika. Ama sadece% 99'luk kod testiyle test kapsamı dahilinde mi? Sadece ünite testlerinden bu kadar fazla kapsam alabileceğine inanmanın zor olduğunu düşünüyorum .

3 gün geçirdiğiniz durumda, aksi takdirde uygulamanız 1 gün süren bir ders için testler yazıyor. Neden bu kadar uzun sürdüğünü veya herhangi bir kodu paylaşmadığını ayrıntılı olarak anlatmadınız. Spekülasyondan, sınıfınız için gerçekten gerçek bir ünite testi yazmadığınızı, aslında test otomasyonu yazdığınızı tahmin ediyorum . Ve aslında yanlış bir şey yok - iki farklı test türü arasındaki farkı farkettiğiniz sürece.

Ancak üç günlük test yazımının sadece bir sınıf için olduğunu söylediniz. Belki de sınıfın kendisi birim testi için tasarlanmamıştır. Sınıf UI'yi uygular mı? Ağ? Dosya G / Ç? Öyleyse, Java çalışma zamanını çalışma zamanı ile etkileşime giren iş mantığınızdan daha fazla test etmek için daha fazla kod yazmış olabilirsiniz.

TDD, arayüzler ve bağımlılıklara arayüzler olarak düşünmenizi sağlar. Tek bir özellik için UI, ağ ve dosya / io uygulayan bu tek sınıf, birden çok sınıfa bölünmüş olarak daha iyi bir şekilde sunulabilir - biri ağ, diğeri dosya / io için Daha sonra bağımlılıklar için basit sahte nesnelerle her biri için uygun testleri uygulayabilirsiniz. Tabii ki, bunların hepsi daha fazla zaman alıyor. Kodlamak için 1 gün ve testler yazmak için 3 gün yerine, bu tasarım türü 3 günlük kodlama ve 1 günlük yazma testi gerektirebilir. Ancak kod daha iyi korunabilir ve tekrar kullanılabilir olacaktır.

Birim testleri bakım zamanında karşılığını verir. Uzun ömürlü bir uygulamaya sahip olmayı planlıyorsanız, şimdi düşündüğünüzden daha uzun süre harcayacaksınız (henüz denemediyseniz başarılı bir projenin ne kadar süre yaşayabileceğini görünce şaşıracaksınız).

İstediğiniz şey, eğer işlevselliğinizi yanlışlıkla değiştirirseniz , testleriniz bozulur ve bu gibi şeyleri mümkün olduğu kadar çabuk bulursunuz. Müşteriler, işlevsellik beklenmedik biçimde değiştiğinde kesinlikle beğenmezler.

TDD yapıyorsanız, testleri kodla aynı anda yazacaksınız, birkaç dakikada bir (veya daha az) aralarında geçiş yapacaksınız. Testler için harcanacak belirli bir süre olmayacak. TDD'yi kullanmak, sağlam bir test kapsamına sahip olduğunuzu bilmenizi kolaylaştırır.

Gerçekliğin ardından Birim testi yapıyorsanız, değişiklikler nedeniyle kodun bozulduğunu size söyleyecek testleri yazmanız gerekir. Buradaki kapsama metriklerine güvenmezdim, ancak kamuya açık arayüzlerde kullanım durumlarına ve parametrelerine dayanarak giderdim. Bu nihayetinde sizin zevkinize ve deneyiminize dayanacaktır.

Testler için zaman harcamazsanız, canlı kodda hata ayıklamak için daha da fazla zaman harcarsınız.
Bu nedenle, testleri (tümünü kodun% 99'unu) kapsayacak şekilde test etmek için gerektiği kadar zaman harcayın.

Diğerlerinin de belirttiği gibi, büyük ölçüde yazılımın türüne bağlıdır. Bahsettiğiniz 3: 1 test / geliştirme süresi oranı ortalama projeler için biraz fazla olabilir, ancak kritik uygulamalar için mükemmel olabilir ve kritik bir sistem için bile çok az olabilir.

% 99 + birim test kapsamı, ortalama bir uygulama durumunda beklenebilecek çok fazla olabilir ancak hayati öneme sahip bir proje için çok azdır.

Tecrübelerime göre, üretim kodunun önemli bir bölümünün hata işleme kodu olduğu düşünüldüğünde, çoğu uygulama için% 80-90'lık bir kapsama alanı yeterli olacaktır ve bu, kabaca yaklaşık% 80'i birim kod yazarken, üretim kodunu yazmak için gerekli olabilir. (Sonra yine, eğer biri TDD tarzında ciddi şekilde çalışıyorsa, ikisi pratikte tek bir görev haline gelmek için tamamen iç içe geçmiştir, bu yüzden kişi yalnızca gerçek oranı tahmin edebilir.)