TDD kullanarak iyi bir karmaşık kod örneği [kapalı]


37

TDD'nin büyük, gerçek hayat, karmaşık projelerde kullanımına iyi bir örnek olabilir mi? Şimdiye kadar gördüğüm tüm örnekler, bir kitap ya da bildiri amaçlı oyuncak projeleri.

TDD'yi yoğun olarak kullanan açık kaynaklı bir projeyi adlandırabilir misiniz? Tercihen C ++ ile Java ve C # veya diğer benzer dilleri okuyabilirim.


soruna cevap vermek zor. otomatik testleri kullanan birçok proje var, ancak TDD felsefesini ne kadar takip ettiklerini söylemek zor çünkü muhtemelen onu desteklemiyorlar. Ayrıca c ++, c # ve java türlerinin test edilmesi zor gui uygulamalarında kökleri vardır. genellikle çerçeveler veya kütüphaneler içinde daha fazla test bulacaksınız.
iMacUwhAK

İyi bir cevap bulmakla ilgilenmemin nedeninin bir kısmı şu anda bir C ++ motoru ve bir Java GUI ile bir masaüstü uygulaması üzerinde çalışıyorum ...
Xavier Nodet

Yanıtlar:


19
  • JUnit % 100 test odaklı geliştirilmiştir. Aslında, geliştirilen% 100 test odaklı JUnit Kent Beck birkaç kez gerçekten mindbending egzersiziydi dediği gibi.
  • Ben inanıyorum Sun'ın ZFS dosya sistemi test odaklı geliştirilmiştir.
  • İçin ikj tercüman Ioke dilin kendisi programlama dili (JVM), Ioke programlama dili (CLI), tüm Ioke çekirdek ve standart kütüphane için IKC tercüman ve aslında% 100 test odaklı (aslında davranış odaklı geliştirilen ).

DUnit - Delphi'nin test çerçevesi, DUnit'in kendisi için eksiksiz bir test paketi ile birlikte gelir. Ve Kent ile aynı fikirdeyim, bu biraz zihin bükme. ;-)
Nick Hodges

14

SQLite. Tüm kodları çok, çok yoğun bir şekilde test edildi :

3.7.14 sürümünden itibaren, SQLite kütüphanesi yaklaşık 81.3 KSLOC C kodu içermektedir. (KSLOC binlerce "Kod Satırı Kodu" veya başka bir deyişle, boş satırlar ve yorumlar hariç kod satırları anlamına gelir.) Karşılaştırmaya göre, projede 1124 kat fazla test kodu ve test komut dosyası var - 91421.1 KSLOC.


1
vay, onlar çok test var: |
Luca Matteis

8
yoğun bir şekilde test edilmiş olması, mutlaka bir test sürüşü (TDD) şeklinde geliştirildiği anlamına gelmez. Öylemiydi? (Bu sayfanın tamamını okumamıştım, ancak sayfa içi aramalarda ne "TDD" ne de "yönlendirilmiş" gördüm, bu yüzden cevabını bilmiyorum.)
10:01

1
@lindes: TDD'yi kesinlikle takip etmiyor gibi görünüyorlar, ancak örneğin her hata raporu için önce bir test yapıyorlar. Ayrıca her taahhüt için testler yapıyorlar. Yani en azından kısmen bu TDD'dir.
liori

9

FitNesse'nin TDD ile yazıldığını hatırlarsam ve projeye asıl katkıda bulunan Bob Martin Amca, bu yüzden muhtemelen gerçekten temiz kod


Sadece ona bir göz vardı ve bir gerçekten temiz kodu.
Robert Harvey,

3

Microsoft'taki P&P Ekibi ile yaptığım görüşmelerden itibaren Enterprise Library TDD ile yazılmıştır.


Enterprise Library 5.0'ı çıkardım ve kaynak koduna baktım. Kapsamlı bir test koleksiyonuna sahiptir, ancak test projesinde birçok test fikstürü, çağrı tutucusu ve diğer karmaşık nesneler vardır; neredeyse kendi başına bir uygulama gibi görünüyor. Çalışmalara hayran kalırken, TDD dünyasına kırmızı-yeşil refaktör görüşüne nasıl uyduğunu görmüyorum.
Robert Harvey,

@Robert - Sana sadece bana ne söylediklerini söyleyebilirim ... Yazarken TDD kullandılar.
Walter

6
@Robert - Test odasının kendi başına bir yaşam sürmesi alışılmadık bir durum değil. DRY hem uygulamanız hem de testleriniz için geçerlidir. TDD'de şu ana kadar sadece 4 şeyden birini yapıyorsunuz: Test yazma, kod yazma, yeniden düzenleme testleri, yeniden düzenleme kodu. Tüm bunları kırmızı-yeşil-refactor düzeninde yapıyorsanız, TDD yapıyorsunuz demektir.
Jeff Knecht

1
@Jeff: Bunu açıkladığınız için teşekkürler. TDD'nin açıklanma şekli (indirgemeci, mekanik terimlerle) ile gerçek dünya senaryolarında gerçekte nasıl kullanıldığı arasında bazı farklılıklar olduğunu düşünüyorum.
Robert Harvey,

3

TDD'yi kullanan açık kaynaklı herhangi bir projeyi adlandıramıyorum, ancak TDD'nin kullanıldığı gerçek hayattaki projeler üzerinde çalıştığımı söyleyebilirim ... ve bir cankurtaran!


1
Siz veya başkaları bu deneyimleri paylaştı mı? İyi bir savaş hikayesi gibi geliyor.

biraz tweetledim ve diğer yazılardaki noktaları göstermek için fıkralar kullandım. Test-ilk tasarım ve otomatik test takımları hayatımı çok daha kolaylaştırıyor, geri dönmeyeceğim ve başka bir şekilde geliştirme yapamayacağımı söylemeye yetecek kadar. Örnek: bir test durumunda elle yapılan testin bulunamayacağındaki ince hata (çünkü manuel test cihazları her işlemden sonra veritabanı bütünlüğünü kontrol etmiyor); 40 saatin üzerinde manuel test süresine eşdeğer olan, bunu anlamak için o gün birçok kez test davası yürüttü. Geçenlerde 1000'in üzerinde kod değişikliği yaptım ve uyurken testleri yaptım. TDD kayalar.
Steven A. Lowe

Sana inanıyorum. Sadece hikayeleri duymayı severim. QuickCheck'i ilginç bulabilirsiniz - en.wikipedia.org/wiki/QuickCheck - 15 yıllık üretim kodunda çok iş parçacığı hataları bulunan bir sunum gördüm.

"çünkü manuel test cihazları her işlemden sonra veritabanı bütünlüğünü kontrol etmiyorlar" - kısıtlamalar ve iyi tasarlanmış bir DB şeması daha fazla etkiliyor ve sizi hatayı görmüş olduğunuz gibi bir gün test etmek zorunda kalmaktan kurtarıyor. .
gbjbaanb,

@gbjbaanb: bu durumda, 'çek' basit şema bütünlüğünden çok daha karmaşıktı, bu yüzden otomatik bir test var
Steven A. Lowe

0

Tamamen TDD'de yaptığım ilk projem 2002'de açık kaynaklı bir projeydi. Hala burada bulabilirsiniz:

http://sourceforge.net/projects/camelos/

Şimdi işte çoğunlukla TDD'de çalışıyorum ama ekibimizdeki herkes yapmıyor, testleri günün sonunda yazması şartıyla iyi.

Ayrıca çekirdek kısım için TDD kullanarak eksiksiz bir gwt gae uygulaması yazdık. http://netnumero.appengine.com/company/mycompany

Bu kodu serbest bırakamıyorum, ancak kullanıcı arayüzünde de TDD kullanan GWT için TDD'de yapılan tam bir örnek proje üzerinde çalışıyorum.

İşim biter bitmez (Noel tatili) buraya göndereceğim https://github.com/ubertob/gwt-tdd-example

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.