TDD ve Verimlilik

Mevcut projemde (bir oyunda, C ++), geliştirme sırasında% 100 Test Güdümlü Geliştirme kullanmaya karar verdim.

Kod kalitesi açısından bu harika oldu. Kodum hiç bu kadar iyi tasarlanmış ya da hatasız olmamıştı. Projenin başlangıcında bir yıl önce yazdığım kodu görüntülerken cüruf etmiyorum ve sadece daha kolay test edilebilir olmak için değil, uygulama ve kullanımda daha kolay olmak için işleri nasıl yapılandıracağımla ilgili daha iyi bir anlam kazandım. .

Ancak ... projeye başladığımdan bu yana bir yıl geçti. Kabul ediyorum, sadece boş zamanlarımda çalışabiliyorum, fakat TDD alışkın olduğum durumla karşılaştırıldığında beni hala yavaşlatıyor. Daha yavaş gelişim hızının zamanla daha iyi olduğunu okudum ve kesinlikle testler alıştığımdan çok daha kolay testler yapıyorum, ancak bir yıldır bu işteyim ve hala bir salyangoz hızında çalışıyorum.

İşe ihtiyacı olan bir sonraki adımı düşündüğümde, her zaman durmalı ve gerçek kodu yazmama izin vermek için nasıl bir test yazacağımı düşünmeliyim. Bazen tam olarak hangi kodu yazmak istediğimi bilerek, ancak testlerle tam olarak örtecek kadar ince bir şekilde nasıl parçalanacağını bilmeyerek saatlerce takılıp kalırım. Diğer zamanlarda, hızlıca bir düzine test düşüneceğim ve bir saat yazma testini geçirerek, aksi halde yazmak birkaç dakika sürecek küçük bir gerçek kod parçasını kapsayacak.

Veya, oyunda belirli bir varlığı ve yaratılması ve kullanılmasının tüm yönlerini kapsayacak şekilde 50. testini bitirdikten sonra yapılacaklar listeme bakıyorum ve kodlanacak bir sonraki varlığı görüyorum ve yazı düşüncesine dehşete düşüyorum uygulamak için başka 50 benzer testler.

Geçtiğimiz yılın ilerlemesine bakarken, "lanet olası projeyi bitirmek" için TDD'yi bırakmayı düşünüyorum. Ancak, birlikte gelen kod kalitesinden vazgeçmek, dört gözle beklediğim bir şey değil. Test yazmayı bırakırsam, kodu çok modüler ve test edilebilir hale getirme alışkanlığımdan kaçıracağımdan korkuyorum.

Belki de hala bu kadar yavaş olması için yanlış bir şey yapıyorum? Yararlarını tamamen kaybetmeden üretkenliği hızlandıran alternatifler var mı? TAD? Daha az test kapsamı? Diğer insanlar tüm verimlilik ve motivasyonlarını kaybetmeden TDD'den nasıl kurtulurlar?

Deneyiminizi paylaşmanız ve endişelerinizi dile getirmeniz için size teşekkür ederek başlayalım ... ki bu nadir değil.

• Zaman / Verimlilik: Yazma sınavları yazmama sınavlarından daha yavaştır. Eğer bunu kapsamlarsan, aynı fikirdeyim. Bununla birlikte, TDD olmayan bir yaklaşımı uyguladığınız paralel bir çaba harcarsanız, olasılıkla break-scan-debug-and-fix mevcut kodunuzu harcadığınız zaman sizi net negatife koyar. Benim için, kod güvenimden ödün vermeden gidebileceğim en hızlı TDD. Yönteminizde, değer katmayan şeyler bulursanız, bunları kaldırın.
• Test sayısı: N kodunu yazdıysanız, N testini yapmanız gerekir. Kent Beck'in satırlarından birini parantez etmek için " Çalışmasını istersen test et. "
• Saatlerce takılıp kalıyorum: Ben de yapıyorum (bazen ve hattı durdurmadan önce> 20 dak.) .. Sadece tasarımın biraz çalışması gerektiğini söyleyen kodunuz. SUT sınıfınız için bir test başka bir müşteridir. Eğer bir test, türünüzü kullanmanın zor olduğunu düşünüyorsa, üretim müşterileriniz de aynı şekilde olacaktır.
• Benzer testler tedium: Bir karşı yazmam için bu benim için daha fazla içeriğe ihtiyaç duyuyor. Bu, Dur ve benzerlik hakkında düşünmek dedi. Bu testleri bir şekilde verilendirebilir misin? Taban tipine karşı testler yazmak mümkün mü? O zaman, sadece her bir türev için aynı test grubunu çalıştırmanız gerekir. Testlerini dinle. Doğru tembel olun ve todyumdan kaçınmanın bir yolunu bulup bulamayacağınıza bakın.
• Daha sonra yapmanız gerekenler hakkında düşünmeyi bırakmak (test / spec) kötü bir şey değil. Aksine, “doğru olanı” inşa etmeniz önerilir. Genellikle nasıl test edileceğini düşünemezsem, genellikle uygulamayı da düşünemiyorum. Oraya kadar uygulama fikirlerini boşaltmak iyi bir fikirdir .. belki de daha basit bir çözüm YAGNI önleyici tasarımıyla gölgede kalıyor.

Ve bu beni son sorguya getiriyor: Nasıl daha iyi olabilirim? (Veya An) cevabım Okuma, Yansıtma ve Uygulamadır.

örneğin, geç saatlerde sekmeleri tutarım

• ritmimin RG [Ref] RG [Ref] RG [Ref] yansıtması mı yoksa RRRRGRRef mi olduğu.
• Kırmızı / Derleme Hatası durumunda harcanan% zaman.
• Kırmızı / Kırık bir yapı halinde sıkışmış mıyım?

% 100 test kapsamına ihtiyacınız yok. Pragmatik olun.

TDD hala beni yavaşlatıyor

Bu aslında yanlış.

TDD olmadan, birkaç hafta boyunca çoğunlukla çalışan ve ertesi yıl "sınama" yaparak ve birçok hata gidererek (hepsi değil) kod yazıyorsunuz.

TDD ile, gerçekten çalışan bir kod yazıyorsun. Sonra birkaç haftalığına son entegrasyon testini yaparsınız.

Geçen zaman muhtemelen aynı olacak. TDD yazılımı büyük ölçüde daha iyi kalitede olacaktır.

Veya, oyunda belirli bir varlığı ve yaratılması ve kullanılmasının tüm yönlerini kapsayacak şekilde 50. testini bitirdikten sonra yapılacaklar listeme bakıyorum ve kodlanacak bir sonraki varlığı görüyorum ve yazı düşüncesine dehşete düşüyorum uygulamak için başka 50 benzer testler.

Bu bana TDD'nin "Refactor" basamağını ne kadar takip ettiğinizi merak ediyor.

Tüm testleriniz geçerken, kodu yeniden gözden geçirmeniz ve çoğaltmayı kaldırmanızın zamanıdır. İnsanlar genellikle bunu hatırlarken, bazen bunun aynı zamanda testlerini yeniden düzenlemenin, çoğaltmayı kaldırmanın ve işleri basitleştirmenin zamanının geldiğini unuturlar .

Kodun yeniden kullanımını sağlamak için bire birleşen iki varlığınız varsa, testlerini de birleştirmeyi düşünün. Gerçekten de, yalnızca kodunuzdaki artımlı farkları test etmeniz gerekiyor . Testlerinizde düzenli olarak bakım yapmıyorsanız, hızlı bir şekilde hantallaşabilirler.

TDD hakkında yardımcı olabilecek birkaç felsefi nokta:

• Bir testin nasıl yazılacağını bulamıyorsanız, kapsamlı deneyime dayalı yazma testlerine rağmen, bu kesinlikle bir kod kokusu . Kodunuz bir şekilde modülerlikten yoksundur, bu da küçük, basit testlerin yazılmasını zorlaştırır.
• TDD kullanılırken bir miktar kod yazılması mükemmel şekilde kabul edilebilir. Nasıl göründüğü hakkında bir fikir edinmek için istediğiniz kodu yazın, sonra kodu silin ve testlere başlayın.
• Son derece katı TDD'yi egzersiz şekli olarak görüyorum. İlk başladığınızda, kesinlikle her seferinde önce bir test yazın ve devam etmeden önce testi geçmek için en basit kodu yazın. Ancak, uygulamada daha rahat olduğunuzda bu gerekli değildir. Yazdığım her olası kod yolu için bir birim testim yok, ancak deneyimlerimle bir birim testi ile neyin test edileceğini ve bunun yerine fonksiyonel veya entegrasyon testi ile nelerin kapsanabileceğini seçebiliyorum. TDD'yi bir yıldan beri sıkı bir şekilde uygularsanız, bu noktaya da yakın olduğunuzu hayal ediyorum.

EDIT: Birim test felsefesi konusunda, şunu okumanın ilginç olabileceğini düşünüyorum: Testivus'un Yolu

Ve daha pratik, mutlaka çok yardımcı olmuyorsa, şunu işaret edin:

• Geliştirme dili olarak C ++ 'dan bahsediyorsunuz. JUnit ve Mockito gibi mükemmel kütüphaneler kullanarak TDD'yi Java'da yoğun olarak kullandım. Ancak, C ++ 'da TDD'yi kütüphane eksikliğinden dolayı (özellikle alaycı çerçeveler) çok sinir bozucu buldum. Bu nokta mevcut durumunuzda size çok yardımcı olmamakla birlikte, TDD'yi tamamen kesmeden önce göz önünde bulundurmanızı umuyorum.

Çok ilginç bir soru.

Unutulmaması gereken, C ++ 'ın çok kolay test edilemediği ve oyun oynamanın TDD için çok kötü bir aday olduğu. OpenGL / DirectX'in X sürücüsüyle kırmızı üçgen, Y sürücüsüyle kolayca sarı renk çizip çizmediğini test edemezsiniz. Kabartma eşlemi normal vektör, gölgelendirici dönüştürdükten sonra çevrilmiş değilse. Ayrıca, kırpma sürümlerini farklı sürümlerdeki sürücü sürümleri üzerinde test edemezsiniz. Yanlış aramalar nedeniyle tanımsız çizim davranışı da yalnızca doğru kod incelemesi ve eldeki SDK ile test edilebilir. Ses aynı zamanda kötü bir aday. Oyunlar için oldukça önemli olan çoklu okuma, birim testi için oldukça yararsız. Bu yüzden zor.

Temelde oyun bir çok GUI, ses ve iş parçacığıdır. GUI, WM_'ye gönderebileceğiniz standart bileşenlerde bile, ünite testi zor.

Bu nedenle test edebileceğiniz şey, model yükleme sınıfları, doku yükleme sınıfları, matris kütüphaneleri ve bazı kodlar. Bunlar, çok fazla kod olmayan ve çoğu zaman, yalnızca ilk projeniz ise, tekrar kullanılamaz nitelikte. Ayrıca, bunlar özel biçimlerde de paketlenmiştir, bu nedenle, modlama araçlarını vb. Serbest bırakmadığınız sürece 3. taraf girişlerinin çok fazla farklı olması muhtemel değildir.

Sonra yine, TDD gurusu veya evangelisti değilim, bu yüzden hepsini bir tuz tuzu ile alın.

Muhtemelen ana çekirdek bileşenler için bazı testler yazarım (örneğin matris kütüphanesi, resim kütüphanesi). abort()Her işlevde beklenmeyen girdilerden bir demet ekleyin . Ve en önemlisi, kolay kırılmayan dayanıklı / esnek koda odaklanın.

Tek bir hatayla ilgili olarak, C ++, RAII ve akıllıca akıllıca kullanılması, onları önlemenin uzun bir yoludur.

Eğer oyunu serbest bırakmak istiyorsanız, temelde sadece temelleri örtmek için yapacak çok şeyiniz var. TDD'nin yardımcı olacağından emin değilim.

Diğer cevaplara katılıyorum, fakat aynı zamanda çok önemli bir nokta eklemek istiyorum: Yenileme maliyetleri !!

İyi yazılmış birim testleriyle, kodunuzu tekrar yazabilirsiniz. İlk olarak, iyi yazılmış birim testleri, kodunuzun amacının mükemmel bir şekilde belgelenmesini sağlar. İkincisi, yeniden yapılandırmanın herhangi bir talihsiz yan etkisi var olan test odasına alınacaktır. Bu nedenle, eski kodunuzun varsayımlarının yeni kodunuz için de geçerli olduğunu garanti ettiniz.

Diğer insanlar tüm verimlilik ve motivasyonlarını kaybetmeden TDD'den nasıl kurtulurlar?

Bu benim deneyimlerimden tamamen farklı. Siz ya inanılmaz derecede zekisin ve hata yapmadan kod yazıyorsunuz, (örneğin tek bir hatayla) ya da kodunuzun programınızın çalışmasını engelleyen hatalar olduğunu farketmiyorsunuz ve bu yüzden aslında bitmedi.

TDD, sizin (ve ben!) Hata yaptığınızı bilmek için alçakgönüllülüğe sahip olmakla ilgilidir.

Benim için en içten yazma zamanı, TDD kullanılarak baştan başlayarak yapılan projeler için azaltılmış hata ayıklama süresinden daha fazla tasarruf sağlıyor.

Hata yapmazsanız, TDD belki de sizin için olduğu kadar önemli değil!

Sadece birkaç sözüm var:

1. Her şeyi test etmeye çalışıyorsun . Muhtemelen, belirli bir kod / yöntem parçasının sadece yüksek riskli ve ileri vakalarını yapmamalısınız. 80/20 kuralının burada geçerli olduğundan eminim: Kodunuzun son% 20'si veya kapsanmayan davalar için% 80 yazma testi yapıyorsunuz.

2. Öncelik. Çevik bir yazılım geliştirme sürecine katılın ve bir ay içinde piyasaya sürmek için gerçekten gerçekten ne yapmanız gerektiğinin bir listesini yapın. O zaman salıverin, aynen böyle. Bu özelliklerin önceliği hakkında düşünmenizi sağlayacaktır. Evet, karakterin bir geri dönüş yapabilirse harika olurdu, ama işletme değeri var mı?

TDD iyidir, ancak yalnızca% 100 test kapsamı hedeflemiyorsanız ve sizi gerçek iş değeri üretmekten alıkoymazsa (örneğin, oyununuza bir şey ekleyen şeyler).

Evet, testler ve kod yazmak sadece kod yazmaktan daha uzun sürebilir - ancak kod yazmak ve ilgili birim testleri (TDD kullanarak) kod yazmak ve hata ayıklamaktan çok daha öngörülebilirdir.

TDD kullanılırken hata ayıklama neredeyse ortadan kalkar - bu da tüm geliştirme sürecini daha öngörülebilir ve sonunda yapar - tartışmasız şekilde hızlandırır.

Sürekli yeniden düzenleme - kapsamlı ünite test paketi olmadan ciddi yeniden yapılandırma yapmak mümkün değildir. Bu birim test tabanlı güvenlik ağını oluşturmanın en etkili yolu TDD'dir. İyi biçimlendirilmiş kod, kodu koruyan tasarımcı / ekibin genel verimliliğini önemli ölçüde artırır.

Oyununuzun kapsamını daraltmayı düşünün ve birisinin oynayabileceği bir yere ya da bırakın. Oyununuzu serbest bırakmak için çok uzun süre beklemeden test standartlarınızı koruyun, sizi motive etmek için orta bir temel olabilir. Kullanıcılarınızın geri bildirimleri uzun vadede faydalar sağlayabilir ve testleriniz eklemeler ve değişiklikler konusunda rahat hissetmenizi sağlar.