Tüm ekip kullanıldıktan sonra TDD'nin asıl yükü nedir?

TDD ile ne kadar zaman tasarrufu yapılır ve maliyeti vardır.

Bir proje yaşam döngüsü boyunca bu maliyet ve ödül değişikliklerinin yüzdesini kabul ediyorum.

İlk etabın çok daha fazla maliyeti olduğunu, ancak çok az ödül verildiğini hayal ediyorum . Daha sonra ( yeniden faktörlendirme sırasında ) testlerinizden faydalanabilirsiniz.

Her yerde zamanınızın% 30-50'sinden birim testi yazdığını duydum . Ancak, bu testleri yazarken harcanan zamanı hesaba katmaz .

Bu konuda herkesin deneyimi ne?

Wes

EDIT Zaman maliyeti kadar tasarruf süresi nedir? Hata düzeltme ve refaktorablity?

Duyduğum her yerde zamanın% 30-50'si birim sınavı yazıyor. Ancak, bu zaman tasarrufu dikkate almaz

Benim tecrübeme göre,% 50'den fazla.

Testi bir kere yazdığınızda, çözümün çok kolay gelme eğilimi vardır. Bu yüzden zamanınızı yazma testlerinizin% 70 -% 75'ini harcamanın garip olduğunu düşünmüyorum, ancak 'üretim kodu' yazarak (kod-test ediliyor) ve neredeyse hiç hata ayıklayıcıya zaman harcamak için çok daha az zaman harcıyorsunuz. .

Ne kadar erken bir hata bulursanız, düzeltmesi o kadar ucuz olur ve TDD buna çok yardımcı olur. Son 2 ayın (8 aylık bir projenin) hataları düzeltmek için harcandığı projeler üzerinde çalıştım ve bu aşama TDD ile neredeyse tamamen ortadan kalkacak.

Bana göre, asıl değer bakımda. Testlerle bir kod tabanının miras alınması, onu değiştirmekten daha az korkmanıza neden olur. Testler geçtikten sonra hiçbir şeyi kırmadığını hissediyorsun. Değişiklik yapmaktan korkmadığınız için, eğer bir şeyler doğru değilse, yeniden yönlendirici olmaya hazırsınız. Bu, kodun daha temiz yapılabileceği, tasarımın daha iyi sığabileceği ve teoride değişikliklerin uygulanabileceği anlamına gelir. Voodoo kodu ile herkesin dokunmaya korkmasıyla zıt ol.

Ünite testlerinizi her çalıştırdığınızda, kodunuzu manuel olarak test etmek için harcadığınız süreyi kendiniz kaydedersiniz.

Testlerinizi yazmak için gerekli olduğunu belirttiğiniz zamanın% 30 ila% 50'si, daha iyi (test edilebilir) bir yazılım tasarımına sahip olmanın yararları ile de büyük ölçüde dengelenmiştir.

Testin manuel olarak yapılması için otomatik bir test yazmanın dört kat sürdüğünü varsayalım. Bu, otomatik testinizi dördüncü yaptığınızda, kendisinin parasını öder. Otomatik testi bundan sonra her çalıştırdığınızda ücretsizdir.

Bu, testin otomatik bir birim testi mi yoksa otomatik bir fonksiyonel test mi olduğunu doğrular. İşlevsel testlerin tümü otomatikleştirilemez, ancak çoğu yapılabilir. Ayrıca, otomatikleştirilmiş test bir kişiden daha güvenilirdir; her seferinde aynı şekilde test yapacak .

Birim testlerinin yapılması, bir yöntemin altında yatan uygulamayı yeniden değerlendirebilmeniz anlamına gelir (performans veya başka nedenlerden dolayı) ve birim testleri yöntemin işlevselliğinin değişmediğini doğrular. Bu özellikle, birim testinin , yöntemin işlevselliğini belirttiği TDD için geçerlidir .

TDD genellikle harcanan zaman ve maliyetten ziyade kod kalitesine göre ölçülür. Bununla birlikte, daha iyi kod kalitesiyle, geliştiriciler ve onlarla çalışan herhangi bir kişi daha iyi çalışabilir (daha az zaman harcar, daha az maliyet, daha mutlu vb.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Testler yazmak, işlevsel ve işlevsel olmayan gereksinimlerin doğrulanmasının otomatikleştirilmesine yardımcı olmak için mükemmeldir. TDD'yi benimsemem için ikna eden bir video (aslında BDD, üst düzey TDD): http://video.google.com/videoplay?docid=8135690990081075324#

• İşlevsel testler yazmak, geliştirme aşamasında daha önce hataların / sorunların tespit edilmesine yardımcı olabilir . Büyük bir kod tabanınız olduğunu varsayalım. Birim testleri / teknik özellikleriyle , yalnızca "Tüm testler geçti" / "2 test başarısız oldu, bkz. Xyz satırı" görmeniz gerekir. Hem geliştirme hem de test yapmak için yalnızca bir geliştiriciler ekibine ihtiyacınız var . Birim testler / gözlük olmadan , etmelisin elle karşılaştırmak beklenen ifadelere basılı ifadeleri ve el / sınıfları hatalar hangi yöntemleri iz. Bunu yapmak için muhtemelen iki ayrı takıma (geliştiriciler ve testçiler) ihtiyacınız vardır.

• Yazılı testler geliştiricilerin ilerlemeyi ve karşılaşılan sorunları açıklamasına yardımcı olur.

• TDD, yönetilebilirliğin, uyarlanabilirliğin ve kod esnekliğinin sağlanmasına yardımcı olur. Geliştiricileri küçük test edilebilir parçalar yazmaya ve onları daha büyük test edilebilir parçalar halinde bir araya getirmeye teşvik eder. Diğer taraftan, (yeniden düzenleme uygulamasının bir parçası), sağlam testler yazmamız şartıyla da çalışır. Sonuç olarak, güzelce yazılmış, modüler bir koda sahip olabiliriz.

TDD ile ne zaman bildiğimiz için mutluyuz:

• Bir müşteri gereksinimler üzerinde değişiklik ister (gereksinimleri karşılayan)
• kod yazmanın daha iyi yolları keşfedildi
• takım arkadaşları kod geliştirme için önerileri var
• kodumuzu başkalarına açıklamamız / iletmemiz gerekir

TDD sıkıcı olabilir, çünkü geliştirme süreci küçük adımlar atar ve böylece tahmin edilebilir hale gelir.

Bizim durumumuzda, bunun% 40'a yakın olduğunu tahmin ediyorum. Ancak bundan daha fazlası olduğu bir aşamadan geçtiğimizi sanmıyorum. Biz o iskelet bir kod hem dışarı tükürüyor geliştiriciler tarafından fleshed alır bir kod jeneratör var ve aynı şekilde fleshed alır bir test paketi. Test çabalarımızın çoğu, tam kapsamı aldığımızdan emin olmak için uygun test verilerinin izlenmesine (veya oluşturulmasına) devam eder.

Uzun vadeli önemli önlemler, sadece kod kalitesi ve kod güveni değil, aynı zamanda akılsız testler yapan ekibi dışlamamasıdır.

Kısa vadeli tedbirler, testlerin otomatikleştirilmesinin ROI'si olacaktır.

örneğin: geçen hafta, bir iç mimari kayması nedeniyle 1000'den fazla kod değişikliği yaptım, otomatik test takımını başlattım ve uyudum.

testlerin çalışması 28 dakika sürdü; hepsi geçti. Aynı 40+ kabul testinin elle yapılması yaklaşık 6 saat sürer.

başka bir örnek: önceki bir yinelemede, test senaryolarından birini manuel testin muhtemelen bulamayacağı bir hatayla karşıladım (otomatik testler db bütünlük kontrollerini neredeyse hiç yapmadıklarını kontrol ediyor). Bu test senaryosunu, çözüp çözmeyi başarmadan önce yaklaşık 50 kez çalıştırmam gerekti. Test senaryosu işlemlerinin manuel olarak yapılması yaklaşık 50 dakika sürer. Yani bu bir günde 41.6 işgücü harcanıyor

otomatik testin YG'sini önceden hesaplamanın bir yolu yoktur, çünkü testleri kaç kez yapmanız gerektiğini tam olarak bilemezsiniz.

ama bana göre, otomatikleştirilmiş testlerin YG'si neredeyse sonsuz

Birim testlerini karmaşık algoritmalarla, otomatik olarak oluşturulabilecek durumlarla ve regresyonlarla sınırlamak için çok yardımcı olabilir.

Bileşen testi genellikle önemsiz kodlar için harika bir iş çıkarır, ayrıca uygulamanın değiştirilmesi çok daha ucuzdur çünkü testler sadece arayüze bağlıdır.

İnce taneli ünite testleriyle tam kapsama, bir uygulamanın değiştirilmesi veya yeniden yapılandırılması için büyük bir ek yüke sahiptir;