Büyük bir şirkette çalışıyorum, ancak masaüstü LOB uygulamaları geliştiren sadece iki kişilik bir ekipte çalışıyorum. TDD'yi bir süredir araştırıyorum ve daha büyük uygulamalar için faydalarını gerçekleştirmek kolay olsa da, TDD'yi uygulamalarımızın ölçeğinde kullanmaya başlama zamanını haklı çıkarmaya çalışıyorum.

Testlerin otomatikleştirilmesinde, sürdürülebilirliğin geliştirilmesinde vb. Avantajlarını anlıyorum, ancak ölçeğimizde, tüm bileşenlerimiz için temel birim testleri bile geliştirme süresini kolayca iki katına çıkarabilir. Zaten son teslim tarihlerine sahip olduğumuzdan, hangi yöne gideceğinizden emin değilim. Çevik yinelemeli geliştirme gibi diğer uygulamalar o zamandan beri mükemmel hale gelirken, küçük bir ekipte TDD'nin verimlilik değiş tokuşlarından bir parça kopuyorum.

TDD'nin avantajları çok sıkı programlara sahip küçük takımlarda ekstra geliştirme süresine değer mi?

Çirkin gerçek, başlangıçta sizi yavaşlatacağıdır . Herhangi bir yeni işlem ya da uygulama biraz hızlanır. Tecrübelerime göre TDD, ilk uygulama ile bakım, hata düzeltme ve genişletme kadar ödeme yapmıyor. Diğerleri için hemen bir ödeme olduğunu biliyorum, bu yüzden her kişinin mevcut kodlama stiline bağlı olacaktır.

TDD'nin büyük bir savunucusu olduğum halde (bunu şu anki işe getirdim) Uygulamayı keşfetmek ve anlamak için biraz nefes alan (son tarihler / zaman çizelgeleri) olması gerektiğini düşünüyorum .

Ekibiniz ne kadar küçük olursa TDD'den o kadar çok faydalanabilirsiniz. Bu ödemeyi 6'dan 3'e kadar takım boyutunda gördüm.

Bahsettiğiniz ekstra geliştirme süresi bir yanılsama olabilir .

TDD'yi standart birim testinden farklı kılan, sadece test yapmak için kullanılmamasıdır.

TDD is a new way of developing software. Bildiğim en iyi yollardan biri.

Bu nedenle, projenizin büyüklüğü ile ilgili değildir. İlk kod satırından faydaları elde edersiniz .

• kodunuzu, bakımı ve yeniden kullanımı daha kolay olacak şekilde yapılandırmaya zorlar. Yazılımınızın tasarımını yönlendirir.
• yeniden düzenlemeyi hızlı, güvenli ve eğlenceli hale getirecektir.
• görevlerin uygulanmasını daha kolay hale getiren daha küçük işlevsellik parçaları yazmanıza yardımcı olur.
• genellikle hata ayıklama görevini daha seyrek yapar.

yaygın yanlış anlama, haydi bağırmama izin ver:

TDD'deki TESTLER ÖZELLİKLERDİR

EOM.

Düzenleme: bana ayrıntılı bir şekilde bildirin: "yazma ... tüm veya bileşenlerimiz için birim testleri " TDD değil , birim testtir. TDD'yi tek kişilik takımlarda rutin olarak büyük bir başarı ile kullanıyorum; getirisi olağanüstü.

TDD hakkında çok iyi bir kitap var. Ünite test sanatı ( resmi site ) .net'te örnekleri var. İyi yanı, "Ünite testini kuruluşa entegre etme" - Bölüm 8 ve "Eski kodla çalışma" - Bölüm 9 gibi konuları göz önünde bulunduran tüm bölümlerin olmasıdır. deneyimlerime dayanarak bunun iyi bir başlangıç ​​noktası olduğuna inanıyorum.

Cevaplarını almanız için birkaç soru var:

1. Koddaki hata düzeltme hatasını çözdükten sonra ne kadar zaman harcıyorsunuz? Bunu nicel olarak belirleyebiliyorsanız, bunun "ekstra" süreye eşit olduğunu veya hatta aştığını görebilirsiniz, bu hataların oluşmasını önlemeye yardımcı olacak testi yazmanız gerekir.

2. Kodu yeniden düzenlemek veya yeni özellik eklemek için görünüşte düz bir düzenleme ne sıklıkta ilgisiz görünüyor? Yine iyi bir test kapsamı ile bunlar azaltılabilir.

Bunlara kesin rakamlar koyamıyor olsanız bile, bu zamanı zaten harcadığınızı gösterebilmeniz gerekir, böylece "ön tarafta" harcayabilirsiniz ve (umarım) çok daha istikrarlı bir ürün elde edebilirsiniz.

İnsanlar benimle ekiplerinde testi benimsemeye başlama hakkında konuştuğunda, her zaman önce testlerin nasıl yürütüleceğini kontrol ederim. Çoğu zaman takımların sürekli bir yapısı yoktur. Sınırlı kaynaklarınız varsa, bir CI sunucusu kurmanın teste ciddi bir baskın başlatmak için bir önkoşul olduğunu öneririm.

Bu kurulumu yaptıktan sonra TDD'yi uygulamaya başlayın. Sistem, akılda tutularak test edilmemişse, mevcut kodu test edilebilir yapmak için mücadele edebileceğinizi ve sistemi yeniden yapılandırmanın pahalı olacağını unutmayın.

TDD ile başlamak için kolay yerler arayarak başlayın - az bağımlılığı olan yeni sınıflar veya modüller. Fayda sınıfları ve veri yapıları genellikle başlamak için iyi şeylerdir.

Kodunuz hakkında düşünme şeklinizi nasıl değiştirdiğine dair bir fikir edinin, ürettiğiniz kodun ne kadar iyi olduğunu ve bu kod hakkında ne kadar emin olduğunuza dikkat edin.

Soruyu gerçekten cevaplamadığımı biliyorum, ama kastım, tüm bunları büyük bir ek maliyet olmadan yapabilmeniz gerektiğidir. İlk örnekleriniz üzerinde çalışırken, projenizin avantajlarını daha iyi anlayacaksınız.

Alt satır - daha yavaş gelişme, ancak birkaç kusur, hataları düzeltmek için çok daha az zaman.

Burada, Davranış Odaklı Gelişimin anında kazançlar gösterdiğini düşünüyorum, ancak test odaklı geliştirmenin yaptığından emin değilim.

Davranış odaklı geliştirmede biletlerinize farklı bir şekilde yaklaşırsınız: iş kişisiyle birlikte oturup bu işlevsellik yığınının sahip olması gereken davranışları tanımlamak için onlarla birlikte çalışırsınız. Bunu blogumdaki bir girişte açıklıyorum (yazı başlığı: Yazma Davranışları ).

İş kişi ile oturmak veya herkesin bu işlevsellikten mutlu olması için sistemin ne yapması gerektiğini daha iyi anlamanız için size ve onlara yardımcı olacak kimseye oturmak. Yürüttüğünüz KG süreci tarafından kabul edilmek için ne yapması gerekiyor.

Test ölçütlerini tanımlamak, ardından bu test ölçütlerini otomatik test takımınıza yazmak, elde ettiğiniz ileri geri miktarını azaltmalıdır: işlevselliği iddia eden biri, bir şeyi kaçırdığınız için (ya bir şeyi meşru bir şekilde kaçırdığınızdan ya da asla söylemedikleri için) hakkında).

Ayrıca başkalarının ekibinizi algılamasına da yardımcı olabilir: eğer oturursanız ve sistemde ne yapılması gerektiğini tanımlarsanız, "her şeyi yenileyip istemediğimiz şeylere zaman harcayan aptallar" dan, msgstr "kullanışlı özellikleri ile gelen akıllı halk".

TP; DR: Davranış Odaklı Geliştirme, "müşteri" odaklı olduğundan hızlı bir şekilde iyileştirmeler gösterebilir. Test Odaklı Geliştirme, bana göre, "hiç kimsenin" umursamadığı ve daha az belirgin iş faydaları sağlayan kod tabanının içsellerini test etmekle ilgili gibi görünüyor. (Davranış Odaklı Gelişme yüzünüzde hemen değişime sahiptir: mühendisler aniden "iyi" bir şey olarak görülmesi gereken bu hakkı elde etmeye çalışmak için "müşteri" veya iş analisti ile çok daha fazla zaman geçiriyorlar. , Özellik X hakkında bir toplantı yapıyorlar, yani bu cephede ilerleme var! ")