TDD olumsuz deneyim [kapalı]

TDD deneyiminizin olumsuz tarafı nedir? Can sıkıcı ve işe yaramaz bebek adımları (testi yeşil yapmak için en basit düzeltme) buluyor musunuz? Değeri olmayan testleri (test başlangıçta mantıklı olduğu halde ancak son uygulamada diğer testlerle aynı mantığı kontrol ettiğinde) buluyor musunuz? vb.

Yukarıdaki sorular TDD deneyimim sırasında rahatsız olduğum şeyler hakkında. Bu yüzden diğer geliştiricilerin de benzer duygulara sahip olup olmadığına ve onlar hakkında ne düşündüklerine ilgi duyuyorum.

TDD’nin olumsuz yönlerini tanımlayan makalelere bağlantılara müteşekkir olur (Google, olumlu ve sıklıkla fanatik makaleler ile doldurulur).

"Çevik" başlığının altına giren her şey gibi, TDD teoride iyi gelen bir şeydir, ancak pratikte ne kadar iyi olduğu net değildir (ve aynı zamanda çoğu "Çevik" şey gibi, yapmazsanız size söylenir. beğen, yanlış yapıyorsun.

TDD'nin tanımı taştan yapılmadı: Kent Beck gibi adamlar derleyici olmayan bir testin tek bir kod satırından önce yazılmasını ve her bir kod satırının başarısız bir testi geçmek için yazılmasını istiyor. Ön tasarım az ve her şey yönlendiriliyortestlerle. Sadece işe yaramıyor. Bu metodoloji kullanılarak geliştirilen büyük bir kurumsal uygulama gördüm ve umarım kariyerimde gördüğüm en kötü kod (çok uzak olmayacak; ve bunun üzerinde çalışan yetenekli geliştiricilerin olmasına rağmen). Gördüklerimden, işlev çağrılarının meydana geldiğini doğrulayan çok sayıda kötü düşünülmüş testle sonuçlanmasına, değişkenler boş olduğunda ve alaycı çerçevenin kapsamlı bir egzersiz yapması durumunda istisnaların ortaya çıkmasına neden olur (whoop-de-whoop); Üretim kodunuz bu testlere büyük ölçüde bağlı kalıyor ve sürekli ve kolay yeniden düzenleme işleminin rüyası görünmüyor - aslında insanların bozacakları tüm testler nedeniyle hatalı kodu düzeltmesi daha da az olası.

Tersine, insanların TDD'nin, mimari tasarımın yanı sıra planlama aşamasının bir parçası olarak testleri ileri düzeyde tasarlamak anlamına geldiğini iddia ettiğini duydum. Bu testler geliştirme sırasında daha fazla bilgi mevcut olduğunda değişebilir, ancak dikkatlice değerlendirilmiş ve kodun gerçekte ne yapması gerektiği konusunda iyi bir rehber sunmuşlardır. Bana göre bu çok mantıklı.

Bu ( Clojure yazar) Rich Hickey röportajı aşağıdakileri içerir. % 100 sempatik hissediyorum:

Hayat kısa ve bir günde sadece sınırlı sayıda saat var. Bu yüzden zamanımızı nasıl harcadığımızla ilgili seçim yapmak zorundayız. Test yazarak geçirirsek, o zaman başka bir şey yapmak için harcama yapmayız. Her birimiz, sonuçlarımızı hem nicelik hem de nitelik olarak en üst düzeye çıkarmak için zamanımızı en iyi şekilde nasıl harcayacağımızı değerlendirmek gerekiyor. Eğer insanlar zamanlarının yüzde ellisini test yazma harcadıklarının sonuçlarını en üst düzeye çıkardığını düşünüyorlarsa - onlar için tamam. Bunun benim için doğru olmadığından eminim - o zaman sorunumu düşünerek geçirmeyi tercih ederim. Benim için bunun zamanımın diğer kullanımlarından daha az hatayla daha iyi çözümler ürettiğinden eminim. Komple bir test paketi ile kötü bir tasarım hala kötü bir tasarımdır.

Donald Knuth bir başka benzer ifade Çalışma de Kodlayıcılarda kitap röportajımızdan-yapıştırılan kopya burada :

Seibel: Pratik çalışmalardan bahsetmişken, Bilgisayar Programcılığı Sanatı Çalışması'nın ortasında, dizgi sisteminizi TeX yazmak için on yıllık bir ara verdiniz. Anladığım kadarıyla TeX'in ilk versiyonunu bilgisayardan tamamen uzak tuttunuz.

Knuth: 1977 ve '78 yıllarında TeX'i orjinal olarak yazdığımda, elbette okuryazar programlamam yoktu, fakat yapılandırılmış programlama yaptım. El yazısıyla büyük bir deftere kurşun kalemle yazdım. Altı ay sonra, tüm projeyi tamamladıktan sonra, bilgisayara yazmaya başladım. Ve ben '78 ekim ayında hata ayıklama yaptım. Bunun kodu Stanford arşivlerinde - hepsi kalemle yazılmış - ve elbette geri gelip ne olması gerektiğini öğrendiğim gibi bir alt rutini değiştirirdim. Bu, ilk nesil bir sistemdi, bu yüzden, bir süre yaşayana ve orada ne olduğunu öğrenene kadar, birçok farklı mimarinin mümkün olması ve atılması gerekiyordu. Ve bir tavuk-yumurta sorunuydu; yazı yazana kadar yazı yazamazdınız, sonra yazı yazana kadar yazı yazamadı. Fakat yapısal programlama bana değişmezler ve nasıl anlayabileceğim kara kutular yapmayı bilme fikrini verdi. Bu yüzden nihayetinde hata ayıklayacağımda kodun işe yarayacağına dair güvenim vardı. Herhangi bir şeyi test etmeden altı ay beklediysem çok zaman kazanacağımı hissettim. Kodun yaklaşık olarak doğru olduğuna yeterince güvenmiştim.

Seibel: Ve zaman tasarrufu, tamamlanmamış kodu test etmek için iskele ve taslak oluşturmak için zaman harcamak zorunda kalmayacağınız için mi?

Knuth: Doğru.

TDD ile olan olumsuz tecrübem ilk oldu. TDD bana harika geliyordu, yıllarca QA yaptım ve hala dehşet aklımdaydı. Bir böcek yapmadan önce her böceği ezmek istedim. Maalesef, TDD'yi kullanmak iyi testler yazacağınızı garanti etmiyor. Aslında benim ilk yatkınlığım basit kod üreten basit testler yazmaktı. Birkaç soyutlama içeren gerçekten basit bir kod. Sınıf içindekiler ile iç içe geçmiş gerçekten basit testler. Ve birkaç bin itty bitty testi yaptırdıktan sonra, çok önemli etki alanı kavramı X'i kullanmak için kodunuzu yeniden düzenlemek için yüzlerce kişiyi değiştirmek zorunda kaldığınızda daha hızlı hareket ediyormuş gibi hissettiğinizden emin değilsiniz.

Işık bana geldi - TDD test etme becerisi değildir. Bu bir tasarım yeteneği. Yalnızca pratikte iyi, basit, uygulanabilir bir koda ve sizi yönlendirdiği tasarım yönlerine dair sürekli farkındalığa yönlendirebilir. Kod kapsamı uğruna testler yazarsanız, kırılgan testler oluşturacaksınız. Soyutlamaları tasarlamanıza yardımcı olacak testler yazıyorsanız, yukarıdan aşağıya kod yazmanın daha zorlu bir yolu. İlk önce kodu arayanın bakış açısıyla görüyorsunuz, bu da bir sınıfın iç dünyasını dış kenarına yansıtmak yerine hayatını kolaylaştırmaya teşvik ediyor.

TDD'nin faydalı olduğunu düşünüyorum ama bu konuda dogmatik değilim. Bu "değersiz testler" bakımları zorlaştırıyorsa - Sil! Testleri kodun geri kalanıyla aynı şekilde ele alıyorum. Yeniden kırılabilir ve işleri daha basit hale getirebilirse, o zaman yapın!

Kişisel olarak görmedim, ancak bazı yerlerin kod kapsamını ve test sayımlarını takip ettiğini duydum. Öyleyse metrik toplama TDD'nin yan etkisi ise, bunu olumsuz olarak da görebiliyorum. 1000 kod satırını coşkuyla silerim, ve bu 20 testi geçersiz kılarsa ve kod kapsamımın% 'sini düşürürse, peki.

Burada bir uzuv üzerinde çıkacağım ve acımasız bir dürüstlükle kelimenin tam anlamıyla bir ritüelist zaman kaybı olduğunu ilan edeceğim . (Çoğu durumda.)

TDD'yi de tartışan Birim Testi hakkında bir kitap aldım ve UTD'nin yararlarına katılırken, TDD'yi denemeden yaklaşık yüz saat sonra, onca nedenden dolayı vazgeçtim. Buraya çapraz gönderme yapıyorum ama TDD:

1. Gerçek dokümantasyondan daha iyi dokümantasyon değil.
2. Hata ya da gerileme yakalamaz .
3. Bazı fonksiyonel programlama ve beste kavramlarını uygularsam, tasarımlarımı, sonuçta olduklarından daha iyi yapmaz .
4. Kod incelemeleri yapmak veya dokümanları ve spesifikasyonları parlatmak için daha iyi zaman harcanması gerekebilir.
5. Yüzlerce yeşil simgenin bir listesini gördüklerinde yöneticilere sahte bir güvenlik hissi verir.
6. Sınırlı giriş-çıkış eşlemeli algoritmaların uygulanmasında üretkenliği arttırır.
7. Ki sen olabilir sakar mı biliyorum sen TDD sonucu ne yaptığını, ancak herhangi bir kazanç değildir anlayış sizin tasarımları yaptıkları şekilde çıkıp neden o kadar iyi çalışır neden.

Diğer bir endişe, başarılı bir şekilde yapmak için TDD'yi yapması gereken tartışmalı mükemmellik derecesidir. Bazıları TDD ekipteki herkes tarafından projenin başlangıcından itibaren ısrarla yapılmazsa, yalnızca acı çekeceğiniz konusunda ısrar ediyor. Diğerleri hiç kimsenin kitapta TDD yapmadığı konusunda ısrar ediyor. Bunların ikisi de doğruysa, TDD uygulayıcılarının farkına veseler de etmeyecekleri acı çekiyorlar.

Tabii ki, TDD benzeri bir şekilde işler yaparak TDD ile kolayca çalışabilecek tasarımlara geleceğiniz tartışılıyorsa, bunu başarmanın çok daha hızlı yolları vardır - yani, aslında kavramları inceleyerek Birleştirmeyi. Dışarıda pek çok kaynak var, hatta birçoğu titiz matematiksel teori bile (büyük ölçüde işlevsel programlamada ama aynı zamanda diğer alanlarda). Neden tüm TDD zamanlarını öğrenerek harcamıyorsun ?

Kültürel olarak, TDD ritüel bir pratik olmanın belirtilerini gösterir. Suçluluk duygusuna biniyor; anlayışı anlama prosedürünü teşvik eder; tonlarca doktrin ve slogan var (“yapana kadar sahte” objektif olarak bakarsanız çok endişe vericidir). Wikipedia'nın "ritüel" kelimesini tanımı aslında oldukça açık:

Psikolojide, ritüel terimi bazen teknik olarak, bir kişi tarafından kaygıyı etkisizleştirmek veya önlemek için sistematik olarak kullanılan tekrarlayıcı bir davranış için kullanılır; obsesif-kompulsif bozukluk belirtisidir.

Eklemek istediğim TDD ile ilgili başka bir endişem:

TDD , geliştirme ekibinin odak noktasında Kalite Kodundan Test Testleri ve Kod Kapsamına kadar yanlışlıkla kaymaya neden oluyor ! Şahsen TDD'yi sevmedim, çünkü beni daha az yaratıcı yapıyor ve yazılım geliştirmeyi sıkıcı bir mekanik işlem yapıyor ! Birim test senaryoları, makul bir şekilde kullanıldığında kullanışlıdır, ancak yazılım geliştirme hedefine bakıldığında yük olur.

Bir teknik direktör olan ve teknik olarak sıkıcı olan bir adamı TDD'ye takıntı haline getirdiğimi biliyorum. Zayıf mimarisi olan yazılımında en az korunabilir kod ile tüm sorunlara sihirli çözümler getireceğine inanması onun için böyle büyülü bir şeydi. Bu projeye ne olduğunu söylememek, elindeki sefilce başarısız oldu, tüm testisleri yeşildi. TDD'nin "davalarımın 99 / 100'ü yeşil" vb. Gibi bir çeşit istatistiki bilgi edinmesine yardım ettiğini ve tasarımdaki kaliteyi asla değerlendiremeyeceği veya iyileştirmeler öneremeyeceği için takıntısının sebebi buydu.

Birincil olumsuz tecrübem, TDD'yi, hiç test yapmayan veya çok temel entegrasyon testlerine sahip olmayan bir programcının kodunu düzenlemek için kullanmaya çalışmak. Bir özellik eklemeye gittiğimde veya belirtilen kodla ilgili bir sorunu çözdüğümde; Önce bir test yazmayı tercih ederim (TDD yolu). Maalesef, kod sıkı sıkıya bağlı, ve çok fazla yeniden düzenleme yapmadan hiçbir şeyi test edemiyorum.

Yeniden yapılanma yine de harika bir alıştırmadır, ancak kodu test edilebilir duruma getirmek için gereklidir . Ve bu adımdan sonra, değişikliklerimin bir şeyleri kırıp kırmadığını görmek için hiçbir kontrolüm ve dengem yok; Uygulamayı çalıştırmak ve her kullanım durumunu incelemek.

Öte yandan, bir TDD projesine özellikler / hataların eklenmesi çok kolaylaşıyor. Doğası gereği, TDD ile yazılmış kod genellikle çalışmak için küçük parçalarla ayrıştırılır.

Her durumda, TDD bir kılavuzdur. Maksimum verimlilik elde ettiğiniz noktayı takip edin. İyi test kapsamı ve ayrıştırılmış kod, iyi yazılmış kod.

Sistemin tasarımına gelince, bazen testlerime çok güvendiğim deneyimini yaşadım. Nitty-gritty uygulama detaylarında, büyük resme bakmak için geri adım atabilmek için temelde çok düşük. Bu genellikle gereksiz yere karmaşık bir tasarımla sonuçlanır. Biliyorum, kodu tekrar gözden geçirmem gerekiyor, ancak bazen adımı daha sık geri alarak çok fazla zaman kazanabileceğim izlenimini edindim.

Bununla birlikte, mimari kararlarınızın çok sınırlı olduğu raylar gibi bir çerçeveniz varsa, bu sorunlar temelde mevcut değildir.

Diğer bir sorun da testlerinize kör olarak güvenmenizdir. Gerçek şu ki - diğer tüm kodlar gibi - testlerinizde de hatalar olabilir. Bu nedenle, uygulamanıza doğru yaptığınız testler konusunda kritik olun.

TDD'nin büyük bir hayranı olarak bazen bu dezavantajları görüyorum

• Neredeyse% 100 kod kapsamı uğruna çok fazla test yazma isteği. Bence test yazmak gerekli değil
  • basit mülk alıcılar / alıcılar için
  • Bir istisna atıldığında her durum için
  • Bu aynı işlevi farklı katmanlar arasında kontrol eder. (Örnek: Her parametre için giriş onayını kontrol etmek için en içindeyseniz, tüm bu testleri bir entegrasyon testi ile de tekrarlamanıza gerek yoktur)

• Benzer kodlar için test kodunun bakım maliyetleri, yalnızca biraz farklı olabilir (kod çoğaltma yoluyla oluşturulabilir (diğer bir deyişle kopyala-yapıştır ile kalıtım yoluyla)). Zaten bir tane varsa, benzer bir tane oluşturmak kolaydır. Ancak, test kodunu yeniden gözden geçirmezseniz, yardımcı yöntemlere kod çoğaltmayı ortadan kaldırarak iş kodunuzun uygulama ayrıntıları değişirse testleri düzeltmek için biraz zamana ihtiyacınız olabilir.

• Zaman baskısı altındaysanız , yapılan testleri düzeltmek yerine, bozuk testleri sınamak (veya yorumlamak) için istekli olabilirsiniz . Bu şekilde testlere olan yatırımınızı kaybedersiniz

TDD'nin değerli olduğu bir oyun geliştiricisi olarak birden fazla senaryoya rastlamadım. Ve olduğu durum, doğada tamamen matematiksel olan ve aynı anda çok sayıda uç vakayı test etmek için katı bir yaklaşıma ihtiyaç duyan bir kod parçasıydı - nadir bir ihtiyaç.

Belki bir gün, bir gün fikrimi değiştirebilirim, ancak XP uygulamaları arasında, acımasızca yeniden düzenleme fikri ve kendi biçimini geliştiren kod fikri çok daha önemlidir ve benim için en büyük üretkenliğe yol açar. James Newkirk'in bir makalesinden bir alıntı :

Basitlik - "İşe yarayabilecek en basit şey nedir?"
Mesaj çok açık. Bugünün gereksinimleri göz önüne alındığında, yazılımınızı tasarlayın ve yazın. Geleceği tahmin etmeye çalışmayın, geleceğin açılmasına izin verin. Bunu genellikle çok öngörülemeyen şekillerde yapar ve beklentiyi genellikle karşılaması çok pahalı bir maliyet yapar. ”

Cesaret ve bahsettiği geri besleme döngülerinin sıkılaştırılması kavramları da aklımda üretkenliğin anahtarıdır.

Olumsuz sınırlı TDD deneyimim, nereden başlayacağınızı bilmek! Örneğin, ben bir şey TDD yapmaya çalışacağım ve ya nerede bir yukarı yeni can (test önemsiz şeyler engelleme başlamak için hiçbir fikrim yok Foonesneyi, bir de iletebilirsiniz Quuxiçin Baz, ve benzeri. Şeyi test etmiyoruz Testleri ) veya eğer mevcut bir projede uygulamaya çalışıyorsam, TDD'de kullanabilmek için çeşitli sınıfları yeniden yazmak zorunda kalacağımı buluyorum. Nihai sonuç, kavramı tamamen terk etmem.

Muhtemelen, tüm şirkette hangi birim testinin (TDD veya başka bir şekilde) olduğunu ve neden iyi bir şey olduğunu bilen tek kişi olduğumda yardımcı olmuyor.

TDD zealotları.

Benim için, kapılarımı çalan uzun bir dinsel saçaklardan sadece bir tanesi, bir şeyleri yapma biçimimin onarılamayacak bir şekilde kırıldığını ve kurtuluşa giden tek yolun İsa, Kent Geri veya Birim Testi olduğunu kanıtlamaya çalışıyorlar.

IMO, en büyük yalanları TDD'nin sizi kurtuluşa daha iyi bir algoritma tasarımı getirecek olmasıdır . TDD'de yazılmış ünlü Soduku çözücüsüne bakın: burada , burada , burada , burada ve burada

Peter Norvig sudoku çözücüsünü TDD kullanarak değil, eski moda mühendislik kullanarak karşılaştırın: http://norvig.com/sudoku.html

TDD'yi bu "fanatik" makalelerden kullanırsanız, yazılımınızın hatasız olduğu hissine kapılmayacaksınız.

TDD'nin bazı faydaları var:

• Sen odaklanmak nasıl yerine problem çözme odaklı ve sonra uygulamadan bir çağrı tutkal arasında (önce test yazmak gibi) kodu ve ne ilk beklemek aramak için. Modülerlik, alay etmeyi ve sarmayı kolaylaştırır.
• Testler, programınızın yeniden yapılanmadan önce ve sonra aynı şekilde çalışmasını sağlar. Bu, programınızın hatasız olduğu anlamına gelmez, ancak aynı şekilde çalışmaya devam ettiği anlamına gelir.

TDD uzun vadeli bir yatırımla ilgilidir. Uygulamanızın bakım moduna ulaştığınızda ve bu noktaya ulaşmak için planlanmamışsa, harcamayı asla geri kazanamayabilirsiniz.

TDD'nin kırmızı-yeşil döngüsünü, bebek adımlarının bir uçağın kontrol listesine benzer olduğunu düşünüyorum. Kalkıştan önce uçaktaki her şeyi kontrol etmek can sıkıcıdır ve can sıkıcıdır (özellikle TDD bebeği adım atıyorsa) ancak güvenliği arttırdığı tespit edilmiştir. Her şeyin işe yaradığını doğrulamanın yanı sıra, esasen uçağı sıfırlar . Başka bir deyişle, her kalkıştan önce bir uçak yeniden başlatılıyor.

TDD hakkındaki olumsuz deneyimim, birçok yeni ve sinirli şeyle hissettiğim bir şey. Aslında TDD'den zevk alıyorum çünkü kodumun geçerliliğini sağlıyor ve daha da önemlisi: Yeni kod ekledikten veya herhangi bir yeniden düzenleme işleminden sonra başarısızlık testlerini tanıyabilirim.

TDD hakkında beni rahatsız eden şey, bu konuda çok fazla kural ya da kılavuz olması. Hala oldukça yeni olduğu için, çoğumuz TDD'de yeni başlayanlar olmak için deneyimliyoruz. Öyleyse bazılarımız için iyi sonuç veren, başkaları için işe yaramayabilir. Söylemek istediğim, TDD'yi gerçekleştirmenin gerçek "yanlış veya doğru" bir yolu olmadığı: Benim için çalışan bir yol var - ve eğer varsa benim takımım.

Testler yazdığınız sürece - üretim kodundan önce veya sonra IMHO gerçekten önemli değil - Teste dayalı testin gerçekten doğru olup olmadığından emin değilim, şu anda belirtilen tüm yönergeleri izlemeniz gerekip gerekmediğinden emin değilim. günlük işler için ideal çözüm. Test yazarken daha iyi bir yol bulursanız, bir blogda yayınlamanız, burada tartışmanız veya bunun hakkında bir makale yazmanız gerekir. Bu nedenle, on yıl içinde, hangi TDD kuralının belirli bir durumda iyi veya olamayacağını varsayabileceğini söyleyebilmek için yeterli deneyimi paylaşmış olabiliriz.

Birden fazla durumda, ertesi gün elimden attığımdan beri sakladığım yazılı bir kod yazdım. TDD ile yeniden başladım ve çözüm daha iyi oldu. Bu yüzden olumsuz TDD deneyimi doğrultusunda fazla bir şey yaşamadım. Ancak, söylendiği gibi, bir problemi düşünmek ve TDD alanı dışında daha iyi bir çözüm bulmak için zaman harcadım .

TDD'nin yeni çıkan sistemler söz konusu olduğunda düşük performans gösterdiğini gördüm. Ben bir video oyunları geliştiricisiyim ve son zamanlarda TDD'yi bir varlık için gerçekçi görünümlü hareketler oluşturmak için çok basit davranışlar kullanan bir sistem oluşturmak için kullandım.

Örneğin, sizi farklı türlerdeki tehlikeli alanlardan uzak tutmaktan ve farklı türlerdeki ilginç alanlardan uzaklaştırmaktan sorumlu davranışlar vardır. Her davranışın çıktısını değiştirmek, son bir hareket yaratır.

Sistemin bağırsakları kolayca uygulandı ve TDD burada her bir alt sistemin ne için sorumlu olacağını belirlemek için kullanışlıdır.

Bununla birlikte, davranışların nasıl etkileşime girdiğini ve daha da önemlisi zaman içinde nasıl etkileşimde olduklarını belirleme konusunda sorunlarla karşılaştım. Çoğu zaman doğru cevap yoktu ve ilk testlerim geçmesine rağmen KG, sistemin çalışmadığı durumlarda yeni vakalar bulabilirdi. Doğru çözümü bulmak için birkaç farklı davranıştan ötürü yinelemem gerekti ve oyunda çalıştıklarını kontrol etmeden önce yeni davranışları yansıtmak için testleri her seferinde güncellediysem, tekrar tekrar testlerimi atmış olabilirdim. Bu yüzden o testleri sildim.

Muhtemelen QA'nın keşfettiği son vakaları yakalayan daha güçlü testler yapmalıydım, ancak böyle bir sisteminiz olduğunda birçok fizik ve oyun sisteminin üstüne oturuyorsanız ve zamanla davranışlarla ilgileniyorsanız, biraz tam olarak ne olduğunu belirtmek için kabus.

Neredeyse kesinlikle yaklaşımımda hatalar yaptım ve TDD sisteminin bağırsakları için dediğim gibi mükemmel bir şekilde çalıştı ve hatta birkaç optimize edici refaktörü destekledim.