TDD açısından bakıldığında, sahte yerine canlı bir son noktaya karşı test yaparsam kötü bir insan mıyım?

TDD'yi dini olarak takip ediyorum. Projelerim tipik olarak% 85 veya daha iyi test kapsamına sahip ve anlamlı test senaryoları var.

HBase ile çok çalışıyorum ve ana müşteri arayüzü HTable, alay etmek için gerçek bir acı. Birim testlerimi yazmak, canlı uç nokta kullanan testler yazmaktan 3 veya 4 kat daha uzun sürüyor.

Felsefi olarak, sahte kullanan testlerin canlı uç nokta kullanan testlere göre öncelikli olması gerektiğini biliyorum. Ancak HTable ile alay etmek ciddi bir acıdır ve canlı bir HBase örneğine karşı test etmekten daha fazla avantaj sunduğundan emin değilim.

Ekibimdeki herkes iş istasyonunda tek düğümlü bir HBase örneği çalıştırıyor ve Jenkins kutularımızda çalışan tek düğümlü HBase örneklerine sahibiz, bu nedenle bu bir kullanılabilirlik sorunu değil. Canlı uç nokta testlerinin çalışması, alay kullanan testlerden daha uzun sürer, ancak bunu gerçekten umursamıyoruz.

Şu anda, tüm sınıflarım için canlı son nokta testleri ve sahte tabanlı testler yazıyorum. Alaycılardan kurtulmak isterdim, ancak sonuç olarak kalitenin düşmesini istemiyorum.

Hepiniz ne düşünüyorsunuz?

• İlk tavsiyem sahip olmadığınız tiplerle alay etmemek . HTable'ın alay etmek için gerçek bir acı olduğunu söylediniz - belki de bunun yerine ihtiyacınız olan HTable özelliklerinin% 20'sini ortaya çıkaran bir Adaptöre sarmanız ve gerektiğinde sargıyı alay etmelisiniz.

• Bununla birlikte, hepinizin sahip olduğunuz türlerden bahsettiğimizi varsayalım. Sahte tabanlı testleriniz, her şeyin yolunda gittiği mutlu yol senaryolarına odaklanıyorsa, entegrasyon testleriniz muhtemelen aynı yolları zaten test ettiği için onları yok eden hiçbir şeyi kaybetmezsiniz.

  Bununla birlikte, test edilen sisteminizin, konuştuğu gerçek somut nesneye bakılmaksızın, işbirlikçisinin sözleşmesinde tanımlanan her küçük şeye nasıl tepki vermesi gerektiğini düşünmeye başladığınızda, izole edilmiş testler ilginç hale gelir. Bu, bazılarının temel doğruluk dediği şeyin bir parçası . Bu küçük vakaların birçoğu ve bunların daha fazla kombinasyonu olabilir. İzole testler hızlı ve yönetilebilir kalırken entegrasyon testleri berbat olmaya başlar.

  Daha somut olmak için, HTable bağdaştırıcınızın yöntemlerinden biri boş bir liste döndürürse ne olur? Boş döndürürse ne olur? Bir bağlantı istisnası atarsa ​​ne olur? Bu edilmelidir Adaptçrünün sözleşmede tanımlanan Bunların hiçbirisini olabilirdi eğer, ve tüketicilerin herhangi edilmelidir bu durumlarla başa çıkmak için hazırlanan , onlar için testler için dolayısıyla ihtiyaç.

Özetlersek: entegrasyon testlerinizle aynı şeyleri test ettiyse , sahte tabanlı testlerinizi kaldırarak hiçbir kalite düşüşü görmezsiniz . Bununla birlikte, ek izole testler (ve sözleşme testleri ) hayal etmeye çalışmak , entegrasyon testleri ile düşünülmesi zor ve / veya yavaş test edilmesi gereken kusurlarla başa çıkarak arayüzlerinizi / sözleşmelerinizi kapsamlı bir şekilde düşünmenize ve kaliteyi artırmanıza yardımcı olabilir.

felsefi olarak, sahte kullanan testler, canlı uç nokta kullanan testlere göre öncelikli olmalıdır

Ben bir nokta olduğunu, en azından düşünüyorum akım devam eden tartışmalar TDD savunucuları arasında.

Benim kişisel görüşüm, alay temelli bir testin çoğunlukla bir arayüz sözleşmesi biçimini temsil etmenin bir yolu olduğunu söylemek dışındadır ; ideal olarak sadece arayüzü değiştirirseniz kırılır (yani başarısız olur) . Ve böyle, Java gibi makul derecede güçlü bir dilde yazılmış ve açıkça tanımlanmış bir arayüz kullanırken, neredeyse tamamen gereksizdir: derleyici arayüzü değiştirip değiştirmediğinizi size söylemiş olacaktır.

Ana istisna, ek açıklamalara veya yansımaya dayanan çok genel bir arayüz kullandığınızda, derleyicinin otomatik olarak polis tarafından kullanılamadığıdır. O zaman bile, alayları kullanarak elle değil, programlı bir şekilde doğrulama yapmanın (eq bir SQL sözdizimi kontrol kütüphanesi) olup olmadığını kontrol etmelisiniz.

Bir 'canlı' yerel veritabanı ile test ederken yaptığınız ikinci durum; htable uygulaması, arayüz sözleşmesini elle yazmayı düşündüğünüzden çok daha kapsamlı bir şekilde onaylar ve uygular.

Ne yazık ki, sahte tabanlı testlerin çok daha yaygın kullanımı testtir:

• testin yazıldığı tarihte kod ne olursa olsun
• kodun var olması ve çalıştırılması dışında herhangi bir özelliği hakkında hiçbir garanti vermez
• bu kodu her değiştirdiğinizde başarısız olur

Bu tür testler elbette görüşte silinmelidir.

Uç nokta tabanlı bir testin çalıştırılması, sahte bir testten ne kadar sürer? Önemli ölçüde daha uzunsa, evet, birim testlerini daha hızlı hale getirmek için test yazma zamanınızın yatırımına değer - çünkü bunları birçok kez çalıştırmanız gerekir. Uç nokta tabanlı testler "saf" birim testleri olmasa da, birimi test etmek için iyi bir iş yaptıkları sürece, bu konuda dini olmak için hiçbir neden yoktur.

Ben guillaume31 yanıtı ile tamamen aynı fikirdeyim, asla sahip olmadığın sahte tipler !.

Normalde testteki bir ağrı (karmaşık bir arayüzle alay etmek) tasarımınızdaki bir sorunu yansıtır. Belki de modeliniz ve veri erişim kodunuz arasında bir soyutlamaya ihtiyacınız var, altıgen bir mimari ve bir depo deseni kullanarak form örneği, bu tür sorunları çözmenin en genel yoludur.

Bir şeyleri kontrol etmek için bir entegrasyon testi yapmak istiyorsanız, bir entegrasyon testi yapın, eğer mantıkınızı test ettiğiniz için bir birim testi yapmak istiyorsanız, bir birim testi yapın ve kalıcılığı izole edin. Ancak bir entegrasyon testi yapmak, çünkü mantığınızı harici bir sistemden nasıl izole edeceğinizi bilmediğinizden (veya bir acısını izole ettiğinizden) büyük bir koku olduğu için, gerçek bir ihtiyaç için değil, tasarımınızdaki bir sınırlama için birim üzerinde entegrasyonu seçersiniz entegrasyonu test etmek.

Ian Cooper'ın şu konuşma formuna bir göz atın: http://vimeo.com/68375232 , altıgen mimarlık ve testten bahsediyor, ne zaman ve ne yapacağı hakkında konuşuyor, gerçek TDD hakkında sizin gibi birçok soruyu çözen gerçekten ilham verici bir konuşma .

TL; DR - Gördüğüm yol, testlere ne kadar çaba harcamanıza ve bunun yerine gerçek sisteminize daha fazla harcama yapmanın daha iyi olup olmayacağına bağlıdır.

Uzun versiyon:

Burada bazı iyi yanıtlar var, ancak benim üstlenmüm farklı: test, kendisi için geri ödeme yapması gereken ekonomik bir faaliyettir ve harcadığınız zaman, geliştirme ve sistem güvenilirliğinde (veya çıkmak istediğiniz başka bir şeyde) kötü bir yatırım yapıyor olabilirsiniz; test yazma değil, bina sistemleri işindesiniz. Bu nedenle, test yazma ve sürdürme çabasını azaltmak çok önemlidir.

Örneğin, testlerden kazandığım bazı temel değerler şunlardır:

• Güvenilirlik (ve dolayısıyla geliştirme hızı): refactor kodu / yeni bir çerçeve entegre etme / bir bileşeni / bağlantı noktasını farklı bir platforma değiştirme, işlerin hala işe yaradığından emin olun
• Tasarım geri bildirimi: klasik TDD / BDD düşük / orta seviye arayüzlerinizde "kodunuzu kullanın" geribildirimi

Canlı bir uç noktaya karşı testler yine de bunları sağlamalıdır.

Canlı bir uç noktaya karşı test etmenin bazı dezavantajları:

• Ortam kurulumu - test çalışma ortamını yapılandırmak ve standartlaştırmak daha fazla iştir ve çok farklı ortam kurulumları çok farklı davranışlara neden olabilir
• Vatansızlık - canlı bir uç noktaya karşı çalışmak, kırılgan ve muhakemesi zor olan mutasyona uğrayan bir son nokta durumuna dayanan yazma testlerini teşvik edebilir (yani bir şey başarısız olduğunda, garip durum nedeniyle başarısız mıdır?)
• Test çalışma ortamı hassastır - eğer bir test başarısız olursa, test, kod veya canlı uç nokta mıdır?
• Çalışma hızı - canlı bir uç nokta genellikle daha yavaştır ve bazen paralel hale getirilmesi daha zordur
• Test için uç durumlar oluşturma - genellikle bir alay ile önemsiz, bazen canlı bir son noktaya sahip bir ağrı (örneğin, kurması zor olanlar taşıma / HTTP hatalarıdır)

Bu durumda olsaydım ve dezavantajlar bir sorun gibi görünmese de , uç noktanın takılması test yazımı önemli ölçüde yavaşlattı, emin olduğum sürece kalp atışında canlı bir uç noktaya karşı test ederdim dezavantajların pratikte bir sorun olmadığını görmek için bir süre sonra tekrar kontrol edin.

Test açısından, mutlak bir zorunluluk olan bazı gereksinimler vardır:

• Test (birim veya başka bir şekilde) hiçbir zaman üretim verilerine dokunmanın bir yolu olmamalıdır
• Bir testin sonuçları asla başka bir testin sonuçlarını etkilememelidir
• Her zaman bilinen bir konumdan başlamalısınız

Bu, testlerinizin dışında durumu koruyan herhangi bir kaynağa bağlanırken büyük bir zorluktur. Bu "saf" bir TDD değil, ama Ruby on Rails ekibi bu sorunu sizin amaçlarınıza göre uyarlanabilecek şekilde çözdü. Raylar test çerçevesi şu şekilde çalıştı:

• Birim testleri çalıştırılırken test yapılandırması otomatik olarak seçildi
• Veritabanı, birim testleri çalıştırılmaya başlandığında oluşturuldu ve başlatıldı
• Birim testleri çalıştırıldıktan sonra veritabanı silindi
• SqlLite kullanılıyorsa, test yapılandırması bir RAM veritabanı kullandı

Tüm bu çalışmalar test kayışına yerleştirildi ve oldukça iyi çalışıyor. Çok daha fazlası var, ancak bu konuşma için temel bilgiler yeterli.

Zaman içinde çalıştığım farklı ekiplerde, kodun test edilmesini teşvik edecek seçimler yapacağız , en doğru yol olmasa bile . İdeal olarak, tüm çağrıları kontrol ettiğimiz kod ile bir veri deposuna sararız. Teorik olarak, eğer bu eski projelerden herhangi biri yeni bir fon elde ederse, geri dönüp dikkatimizi sadece bir avuç sınıfa odaklayarak Hadoop'a bağlı veritabanı olmaktan çıkarabiliriz.

Önemli hususlar, üretim verileriyle uğraşmamak ve test ettiğinizi düşündüğünüzü gerçekten test ettiğinizden emin olmaktır. Harici hizmeti, kodunuzdan bile, talep üzerine bilinen bir taban çizgisine sıfırlayabilmeniz gerçekten önemlidir.