Birim testi bana harika geliyor, ancak önemli bir değeri olan diğerlerini ikna edemediğim sürece gerçekten öğrenmek için zaman harcamam gerektiğinden emin değilim. Diğer programcıları ve daha da önemlisi, yönetimdeki fasulye sayıcılarını, test çerçevesini öğrenmek, testleri yazmak, onları güncel tutmak, vb. İçin harcanan tüm ekstra zamanın kendi masrafını karşılayacağına ve daha sonra bazılarının karşılığını alacağına ikna etmeliyim.

Orada ne kanıt var? Biri birim testini kullanan ve diğeri olmayan iki ayrı ekiple aynı yazılımı gerçekten geliştiren ve sonuçları karşılaştıran oldu mu? Şüpheliyim. Bunu sadece "İnternetten bak, herkes bunun hakkında konuşuyor, bu yüzden yapılacak doğru şey olmalı" diye mi haklı çıkarmam gerekiyor?

Uzman olmayan kişileri, birim testinin çabaya değer olduğuna ikna edecek somut kanıt nerede?

Evet. Bu, NCST'de Boby George ve Laurie Williams tarafından yapılan ve Nagappan ve diğerleri tarafından yapılan bir başka çalışmaya bağlantıdır . Eminim daha fazlası vardır. Dr. Williams'ın testlerle ilgili yayınları onları bulmak için iyi bir başlangıç ​​noktası sağlayabilir.

[DÜZENLEME] Yukarıdaki iki makale özellikle TDD'ye atıfta bulunmaktadır ve TDD'yi benimsedikten sonra ilk geliştirme süresinde% 15-35 artış, ancak yayın öncesi kusurlarda% 40-90 azalma göstermektedir. Tam metin sürümlerine ulaşamıyorsanız , herkese açık bir sürüm bulup bulamayacağınızı görmek için Google Akademik'i kullanmanızı öneririm .

"Diğer programcıları ve daha da önemlisi, yönetimdeki fasulye sayıcılarını, test çerçevesini öğrenmek, testleri yazmak, onları güncel tutmak vb. İçin harcanan tüm ekstra zamanın kendi masrafını karşılayacağına ve daha sonra bazılarının karşılığını alacağına ikna etmeliyim. "

Neden?

Neden sessizce ve gizlice yapmıyorsunuz? Hepsini bir kerede yapmak zorunda değilsin. Bunu küçük parçalar halinde yapabilirsiniz.

Çerçeve öğrenimi çok az zaman alır.

Tek bir test yazmak çok az zaman alır.

Birim testi olmadan, sahip olduğunuz tek şey yazılımınıza biraz güvenmektir. Bir birim testle, yine de kendinize güveniyorsunuz ve en az bir testin geçtiğine dair kanıtınız var.

Tüm gereken bu. Kimsenin yaptığını bilmesine gerek yok. Sadece yap.

Buna farklı bir yaklaşım benimsiyorum:

Kodunuzun doğru olduğuna dair nasıl bir güvenceniz var? Veya ekibinizdeki biri func1 () 'i değiştirdiğinde X varsayımını bozmaz mı? Sizi 'dürüst' tutan birim testleri olmadan, çok fazla güvenceye sahip olduğunuzdan emin değilim.

Testleri güncel tutma fikri ilginçtir. Testlerin kendilerinin sıklıkla değişmesi gerekmez. Üretim koduna göre 3 kat daha fazla test kodum var ve test kodu çok değiştirildi az . Bununla birlikte, geceleri iyi uyumamı sağlayan ve müşteriye sistemi bozmadan Y işlevselliğini uygulayabileceğime dair güvenim olduğunu söylememi sağlayan şey budur.

Belki akademi dünyasında kanıt vardır, ancak ticari dünyada kimsenin böyle bir test için para ödeyeceği hiçbir yerde çalışmadım. Bununla birlikte, benim için iyi çalıştığını, test çerçevesine alışmanın çok az zaman aldığını ve test yazma beni gerçekten , gereksinimlerimi ve tasarımı düşünmemi sağladığını söyleyebilirim; test yazmadı.

Kendini ödediği yer burasıdır: 1) Kodunuza güveniyorsunuz ve 2) Sorunları normalde olduğundan daha erken yakalıyorsunuz. Sen QA adam hey, xyz () fonksiyonu sınırları daha kontrol? Vermedi rahatsız etmedi" demek yok O çünkü O böceği bulmak için almaz Eğer bir ay önce bulundu. Bu iyi gelir O, sizin için, şirket için ve müşteri için iyi.

Açıkçası bu bir anekdot ama benim için harikalar yarattı. Size elektronik tablolar sağlayabileceğimden emin değilim, ancak müşterim mutlu ve nihai hedef bu.

Birim Testi olmadan berbat bir yazılım yazmanın mümkün olduğunu somut kanıtlarla gösterdik. Unit Testing ile berbat yazılımlara dair kanıt olduğuna inanıyorum. Ama konu bu değil.

Unit Testing veya Test Driven Development (TDD), bir test tekniği değil, bir Tasarım tekniğidir. Test odaklı yazılmış kod, olmayan koddan tamamen farklı görünür.

Sorunuz bu olmasa da, yanlış sorulabilecek soruları cevaplamanın (ve diğer raporlar tarafından sorgulanabilecek kanıtları getirmenin) gerçekten en kolay yolu olup olmadığını merak ediyorum. Davanız için sağlam kanıtlar bulsanız bile - başka biri aleyhinde sert kanıt bulabilir.

Teknik personelin nasıl çalışması gerektiğini belirlemek fasulye tezgahlarının işi mi? Daha pahalı olanlara ihtiyacınız olmadığına inandıkları için her durumda en ucuz araçları sağlıyorlar mı?

Bu argüman ya güvene dayalı olarak kazanılır (Agile takımlarının temel değerlerinden biri) ya da kazanan tarafın rol gücüne bağlı olarak kaybedilir. TDD taraftarları rol gücüne göre kazansalar bile, onu kayıp olarak kabul ediyorum.

Birim testine karşı kanıtlarla da ilgileniyorsanız, burada iyi araştırılmış ve düşünülmüş bir makale var:

Birim Testlerinin Çoğu Neden İsraftır Yazan James O Coplien (yalın ve çevik guru)

TDD hakkında kesin olarak birim testinden daha fazlası, burada test odaklı geliştirme yoluyla kalite iyileştirmeyi gerçekleştirmek için bir bağlantı var : Nagappan, E. Michael Maximilien, Thirumalesh Bhat ve Laurie Williams'ın yazdığı dört endüstriyel ekip makalesinin sonuçları ve deneyimleri . Microsoft Ampirical Software Engineering and Measurement (ESM) grubu tarafından yayınlanan ve burada zaten bahsedilmiş olan makale .

Ekip, TDD ekiplerinin TDD olmayan ekiplere göre% 60 ila% 90 daha iyi (kusur yoğunluğu açısından) kod ürettiğini buldu. Ancak TDD ekipleri projelerini tamamlamak için% 15 ila% 35 daha uzun sürdü.

İşte şirketini içeriden değiştiren bir adamın harika ve eğlenceli bir okuması. TDD ile sınırlı değildir. http://jamesshore.com/Change-Diary/ "Fasulye sayaçlarını" uzun bir süre ikna etmediğini ve bunun yerine "gerilla taktikleri" yaptığını unutmayın.

Sadece bu cevaplara daha fazla bilgi eklemek için, akademik ve endüstri arka planı üzerindeki üretkenlik ve kalite etkilerini bulmaya yardımcı olabilecek iki meta-analiz kaynağı var:

Konuk Editörlerin Tanıtımı: TDD — Korkusuz Programlama Sanatı [ bağlantı ]

Tüm araştırmacılar, TDD'nin daha iyi görev odağı ve test kapsamını teşvik ettiği konusunda hemfikir görünüyor. Daha fazla test olması, yazılım kalitesinin daha iyi olacağı anlamına gelmez, ancak programcının test tasarımına artan ilgisi yine de cesaret vericidir. Testi, çok büyük bir potansiyel davranış popülasyonunu örneklemek olarak görürsek, daha fazla test daha kapsamlı bir örnek anlamına gelir. Her test, diğerlerinden hiçbirinin bulamayacağı önemli bir problem bulabildiği ölçüde, testler yararlıdır, özellikle de onları ucuza çalıştırabiliyorsanız.

Tablo 1. Test odaklı geliştirmeye yönelik seçilmiş deneysel çalışmaların özeti: endüstri katılımcıları *

Tablo 2. TDD'nin seçilen ampirik çalışmalarının bir özeti: akademik katılımcılar *

Test Odaklı Geliştirmenin Dış Kalite ve Verimlilik Üzerindeki Etkileri: Bir Meta-Analiz [ link ]

Öz:

Bu makale, Test Odaklı Geliştirmenin (TDD) harici kod kalitesi ve üretkenliği üzerindeki etkisini araştıran 27 çalışmanın sistematik bir meta-analizini sağlar.

Sonuçlar, genel olarak, TDD'nin kalite üzerinde küçük bir pozitif etkiye sahip olduğunu, ancak üretkenlik üzerinde çok az veya hiç farkedilebilir etkisi olmadığını göstermektedir. Bununla birlikte, alt grup analizi, endüstriyel çalışmalarda akademik çalışmalarla karşılaştırıldığında hem kalite gelişiminin hem de verimlilik düşüşünün çok daha büyük olduğunu bulmuştur. TDD ile kontrol grubunun süreci arasındaki test çabası farkının önemli olduğu çalışmalarda daha büyük bir verimlilik düşüşü bulundu. Akademik çalışmalarda, test çabasındaki fark önemli olduğunda, kalitede daha büyük bir gelişme de bulunmuştur; ancak veri eksikliği nedeniyle endüstriyel çalışmalarla ilgili herhangi bir sonuç çıkarılamamıştır.

Son olarak, geliştirici deneyimi ve görev büyüklüğünün moderatör değişkenler olarak etkisi araştırılmış ve görev boyutu ile kalite gelişiminin büyüklüğü arasında istatistiksel olarak anlamlı pozitif bir ilişki bulunmuştur.

Pekala, birim testi kullanmanızı gerektiren bazı büyük şirketler var, ancak küçük bir şirketseniz neden büyükleri taklit edesiniz?

Benim için yıllar önce birim testine başladığımda (bugün çoğunlukla davranış modelini kullanıyoruz) tek bir uygulamadaki tüm yolu kontrol edemememden kaynaklanıyordu.

İlk programlamaya ve bir REPL'e alışmıştım, bu yüzden Birim Testini (Her Fonksiyon için Bir Test) aldığımda, çok fazla derlenen dillere bir REPL geri getirmek gibiydi. Yazdığım her kod satırına eğlenceyi geri getirdi. Tanrıyı hissettim. Bunu sevdim. Daha iyi kod yazmaya daha hızlı başladığımı söylemek için bir rapora ihtiyacım yoktu. Patronumun, çılgınca şeyler yaptığımız için aniden bir son teslim tarihini asla kaçırmadığımızı fark etmek için bir rapora ihtiyacı yoktu. Patronumun, üretken olmayan kod yazmanın bu çok tuhaf özelliği nedeniyle "düz" hataların sayısının (birçok kişiye) neredeyse sıfıra düştüğünü fark etmek için bir rapora ihtiyacı yoktu.

Başka bir posterin zaten yazdığı gibi, Test etmek (doğrulamak) için TDD kullanmıyorsunuz. Ünitenizin (nesne, modül, işlev, sınıf, sunucu, küme) çalıştığı şeyin özelliklerini, davranışını yakalamak için yazarsınız.

Pek çok şirkette farklı bir yazılım geliştirme modeline geçmenin birçok başarısızlık ve başarı öyküsü vardır.

Ne zaman yazacak yeni bir şeyim olsa kullanmaya başladım. İngilizceye çevirmek benim için biraz zor olan eski bir söz var ama:

Yaptığınızı fark etmeyeceğiniz kadar basit bir şeyle başlayın. Bir maraton için antrenman yaparken 9 metre yürüyerek başlayın ve 1 metre koşun, tekrarlayın.

Ünite / entegrasyon testinde bulunan bir hatayı düzeltmenin, canlı sistemde bir kez tamir edilmesinden çok daha az maliyetli olduğunu kanıtlayan istatistikler vardır (bunlar, binlerce gerçek hayat projesini izlemeye dayanmaktadır).

Düzenleme : örneğin, belirtildiği gibi, " Kod Tamamlandı " kitabı bu tür çalışmalar hakkında rapor verir (paragraf 20.3, "Kalite Tekniklerinin Göreceli Etkililiği"). Ancak danışmanlık alanında bunu kanıtlayan özel araştırmalar da var.

Bunun için bir dizi veri noktam var - birim testlerinde beni satan bir deneyimden.

Aylar önce, büyük bir VB6 projesi üzerinde çalışan yeni bir mezundum ve büyük miktarda saklı yordam kodu yazma fırsatım oldu. Yazdığım alt sistemin tüm kod tabanının yaklaşık 1 / 4'ünü oluşturuyordu - 50K'nın yaklaşık 13.000 LOC'si kadar.

Depolanan prosedürler için bir dizi birim testi yazdım, ancak VB6 UI kodu birim testi Rational Robot gibi araçlar olmadan gerçekten mümkün değil; en azından o zamanlar değildi.

Parça üzerindeki QA istatistikleri, tüm alt sistemde yaklaşık 40 veya 50 kusurun ortaya çıktığı şeklindeydi ve bunlardan ikisi depolanmış prosedürlerden kaynaklanıyordu. Bu, 6.500 kod satırı başına bir kusurdur , tüm parça genelinde 1.000-1.200 başına 1'e karşılık . Ayrıca, VB6 kodunun yaklaşık 2 / 3'ünün hata işleme ve günlüğe kaydetme için ortak kod olduğunu ve tüm prosedürlerde aynı olduğunu unutmayın.

Çok fazla el sallamadan, birim testine kusur oranlarında en azından büyüklük derecesinde bir iyileşme atfedebilirsiniz.