TDD hakkında bulduğum şey, testlerinizi ayarlamanın zaman alması ve doğal olarak tembel olduğum için her zaman mümkün olduğunca az kod yazmak istiyorum. Yaptığım ilk şey, kurucumun tüm özellikleri ayarladığını test etmek, ancak bu aşırı mı?
Sorum, size birim testleri hangi ayrıntı düzeyinde yazıyorsunuz?
..ve çok fazla test etme durumu var mı?
Yanıtlar:
Testler için değil, işe yarayan kod için ödeme alıyorum, bu yüzden felsefem, belirli bir güven seviyesine ulaşmak için mümkün olduğunca az test yapmaktır (Bu güven seviyesinin endüstri standartlarına kıyasla yüksek olduğundan şüpheleniyorum, ancak bu sadece kibirli olabilir) . Genelde bir tür hata yapmazsam (bir yapıcıda yanlış değişkenleri ayarlamak gibi), bunu test etmem. Test hatalarını anlamaya meyilliyim, bu yüzden karmaşık koşullu mantığım olduğunda daha dikkatli oluyorum. Bir takım üzerinde kod yazarken, toplu olarak yanlış yapma eğiliminde olduğumuz kodu dikkatlice test etmek için stratejimi değiştiriyorum.
Farklı insanların bu felsefeye dayalı olarak farklı test stratejileri olacaktır, ancak testlerin kodlamanın iç döngüsüne en iyi şekilde nasıl uyabileceğine dair olgunlaşmamış bir anlayış göz önüne alındığında bu bana mantıklı geliyor. Bundan on ya da yirmi yıl sonra, hangi testlerin yazılacağına, hangi testlerin yazılmayacağına ve farkı nasıl söyleyeceğimize dair daha evrensel bir teoriye sahip olacağız. Bu arada, deneyler sırayla görünüyor.
Bozulmasını beklediğiniz şeyler ve uç durumlar için birim testleri yazın. Bundan sonra, hata için düzeltmeyi yazmadan önce, hata raporları geldikçe test senaryoları eklenmelidir. Geliştirici daha sonra şunlardan emin olabilir:
Ekteki yoruma göre - Eğer belirli bir sınıfta zamanla çok sayıda hata keşfedilirse, birim testleri yazmaya yönelik bu yaklaşım sorunlara neden olabilir. Muhtemelen takdir yetkisinin yardımcı olduğu yer burasıdır - yalnızca yeniden oluşması muhtemel hatalar için veya yeniden oluşmalarının ciddi sorunlara neden olacağı yerlerde birim testleri eklemek. Birim testlerinde entegrasyon testinin bir ölçüsünün bu senaryolarda yardımcı olabileceğini buldum - daha yüksek kod yollarını test etmek, daha düşük kod yollarını kapsayabilir.
Her şey olabildiğince basit olmalı, ancak daha basit olmamalıdır. - A. Einstein
TDD ile ilgili en yanlış anlaşılan şeylerden biri, içindeki ilk kelimedir. Ölçek. Bu yüzden BDD ortaya çıktı. Çünkü insanlar ilk D'nin önemli olan Driven olduğunu gerçekten anlamadılar. Hepimiz Testler hakkında biraz fazla ve biraz da tasarımın yönlendirilmesi hakkında düşünme eğilimindeyiz. Ve sanırım bu, sorunuza belirsiz bir cevap, ancak gerçekte test ettiğiniz şey yerine muhtemelen kodunuzu nasıl kullanacağınızı düşünmelisiniz; Bu, Kapsam aracının size yardımcı olabileceği bir şeydir. Tasarım çok daha büyük ve daha sorunlu bir konu.
"Her şeyi" test etmeyi önerenler için: aşağıdaki gibi bir yöntemi "tam olarak test etmenin" farkında olun :int square(int x) yaygın dillerde ve tipik ortamlarda yaklaşık 4 milyar test senaryosu gerektirdiğini anlayın.
Aslında, bu daha da kötü: Bir yöntem void setX(int newX)de yükümlüdür değil dışında başka üyelerinin değerlerini değiştirmek için x- Bunu test ediyoruz obj.y, obj.zbütün çağrıldıktan sonra değişmeden kalır vs. obj.setX(42);?
Yalnızca "her şeyin" bir alt kümesini test etmek pratiktir. Bunu kabul ettiğinizde, inanılmaz derecede basit davranışları test etmemeyi düşünmek daha lezzetli hale gelir. Her programcı, hata konumlarının olasılık dağılımına sahiptir; Akıllı yaklaşım, enerjinizi, hata olasılığının yüksek olduğunu tahmin ettiğiniz bölgeleri test etmeye odaklamaktır.
Klasik cevap "kırılabilecek her şeyi test et" dir. Bunu, set veya get dışında hiçbir şey yapmayan ayarlayıcıları ve alıcıları test etmenin muhtemelen çok fazla test olduğu, zaman ayırmaya gerek olmadığı şeklinde yorumluyorum. IDE'niz bunları sizin için yazmadıkça, siz de yazabilirsiniz.
Senin yapıcı Eğer değil ayar özellikleri sonradan hatalara yol açabilir, o zaman set overkill değil olduklarını test.
Yazacağım sınıfların varsayımlarını kapsayan testler yazıyorum. Testler gereksinimleri zorlar. Esasen, örneğin x asla 3 olamazsa, bu gereksinimi karşılayan bir test olduğundan emin olacağım.
Değişmez bir şekilde, bir durumu kapsayan bir test yazmazsam, daha sonra "insan" testi sırasında ortaya çıkacaktır. O zaman kesinlikle bir tane yazacağım, ama onları erken yakalamayı tercih ederim. Bence asıl mesele testin sıkıcı (belki) ama gerekli olmasıdır. Tamamlanacak kadar test yazıyorum ama daha fazlası değil.
Şimdi basit testleri atlamakla ilgili problemin bir kısmı, gelecekte yeniden düzenleme bu basit özelliği birçok mantıkla çok karmaşık hale getirebilir. Bence en iyi fikir, modül gereksinimlerini doğrulamak için Testleri kullanabilmenizdir. X'i geçtiğinizde Y'yi geri almanız gerekiyorsa, o zaman test etmek istediğiniz şey budur. Daha sonra kodu daha sonra değiştirdiğinizde, X'in size Y verdiğini doğrulayabilir ve daha sonra bu gereksinim eklendiğinde A'nın size B'yi vermesi için bir test ekleyebilirsiniz.
İlk geliştirme yazma testleri sırasında harcadığım sürenin birinci veya ikinci hata düzeltmesinde karşılığını aldığını gördüm. 3 aydır bakmadığınız kodu alma ve düzeltmenizin tüm durumları kapsadığından ve "muhtemelen" hiçbir şeyi bozmayacağından makul ölçüde emin olma yeteneği çok değerlidir. Ayrıca birim testlerinin, yığın izlemenin çok ötesinde hataları önceliklendirmeye yardımcı olacağını göreceksiniz. Uygulamanın ayrı parçalarının nasıl çalıştığını ve başarısız olduğunu görmek, neden bir bütün olarak çalıştıklarına veya başarısız olduklarına dair büyük bir içgörü sağlar.
Çoğu durumda, orada mantık varsa, test edin derim. Bu, özellikle mülkte birden fazla şey ayarlandığında oluşturucular ve özellikleri içerir.
Çok fazla test konusunda tartışmalı. Bazıları her şeyin sağlamlık açısından test edilmesi gerektiğini söyler, diğerleri ise verimli test için sadece kırılabilecek şeylerin (yani mantık) test edilmesi gerektiğini söyler.
Sadece kişisel deneyimlerimden, ikinci kampa daha çok eğilirdim, ama eğer biri her şeyi test etmeye karar verseydi, bunun çok fazla olduğunu söylemezdim ... belki benim için biraz abartılı, ama onlar için çok fazla değil.
Yani, Hayır - genel anlamda "çok fazla" test etme diye bir şey olmadığını söyleyebilirim, sadece bireyler için.
Test Güdümlü Geliştirme, tüm testleriniz başarılı olduğunda kodlamayı bırakmanız anlamına gelir.
Bir mülk için testiniz yoksa, neden onu uygulamalısınız? "Yasadışı" bir atama durumunda beklenen davranışı test etmez / tanımlamazsanız, özellik ne yapmalıdır?
Bu nedenle, bir sınıfın sergilemesi gereken her davranışı test etmek için kesinlikle varım. "İlkel" özellikler dahil.
Bu testi kolaylaştırmak TestFixtureiçin, değeri ayarlamak / almak için uzantı noktaları sağlayan ve geçerli ve geçersiz değerlerin listelerini alan ve mülkün doğru çalışıp çalışmadığını kontrol etmek için tek bir testi olan basit bir NUnit oluşturdum . Tek bir özelliği test etmek şu şekilde görünebilir:
[TestFixture]
public class Test_MyObject_SomeProperty : PropertyTest<int>
{
private MyObject obj = null;
public override void SetUp() { obj = new MyObject(); }
public override void TearDown() { obj = null; }
public override int Get() { return obj.SomeProperty; }
public override Set(int value) { obj.SomeProperty = value; }
public override IEnumerable<int> SomeValidValues() { return new List() { 1,3,5,7 }; }
public override IEnumerable<int> SomeInvalidValues() { return new List() { 2,4,6 }; }
}
Lambdalar ve nitelikler kullanılarak bu daha derli toplu yazılabilir. MBUnit'in bunun gibi şeyler için bazı yerel desteğe sahip olduğunu anlıyorum. Önemli olan nokta, yukarıdaki kodun mülkün amacını yakalamasıdır.
Not: Muhtemelen PropertyTest'in nesnedeki diğer özelliklerin değişmediğini kontrol etmenin bir yolu da olmalıdır . Hmm .. çizim tahtasına geri dönelim.
Mümkün olan maksimum kapsama ulaşmak için birim testi yapıyorum. Bir koda ulaşamazsam, kapsam mümkün olduğu kadar dolu olana kadar yeniden düzenleme yaparım
Kör edici yazma testini bitirdikten sonra, genellikle her hatayı yeniden üreten bir test senaryosu yazarım
Kod testi ile entegrasyon testi arasında ayrım yapmaya alışkınım. Entegrasyon testi sırasında (bunlar aynı zamanda birim testidir, ancak bileşen grupları üzerindedir, dolayısıyla birim testi tam olarak ne içindir) doğru bir şekilde uygulanacak gereksinimleri test edeceğim.
Bu yüzden programımı testler yazarak ne kadar çok kullanırsam, testin ayrıntı düzeyi hakkında o kadar az endişeleniyorum. Geriye dönüp baktığımda, davranışı doğrulama hedefime ulaşmak için mümkün olan en basit şeyi yapıyorum gibi görünüyor . Bu, kodumun istediğimi yaptığına dair bir güven katmanı oluşturduğum anlamına gelir, ancak bu, kodumun hatasız olduğunun mutlak garantisi olarak değerlendirilmez. Doğru dengenin standart davranışı ve belki de bir veya iki uç durumu test etmek olduğunu hissediyorum, ardından tasarımımın bir sonraki bölümüne geçiyorum.
Bunun tüm hataları kapsamayacağını ve bunları yakalamak için diğer geleneksel test yöntemlerini kullanmayacağını kabul ediyorum.
Genelde işe yaraması gerektiğini bildiğim girdi ve çıktılarla küçük başlarım. Ardından, hataları düzelttikçe, düzelttiğim şeylerin test edilmesini sağlamak için daha fazla test ekliyorum. Organik ve benim için iyi çalışıyor.
Çok fazla test edebilir misin? Muhtemelen, ancak genel olarak ihtiyatlı davranmak muhtemelen daha iyidir, ancak bu, uygulamanızın ne kadar kritik olduğuna bağlı olacaktır.
Sanırım iş mantığınızın "özündeki" her şeyi test etmeniz gerekiyor. Getter ve Setter de kabul etmek istemeyebileceğiniz negatif değeri veya boş değeri kabul edebilir. Zamanınız varsa (her zaman patronunuza bağlıdır), diğer iş mantığını ve bu nesneleri çağıran tüm denetleyicileri test etmek iyidir (birim testinden entegrasyon testine yavaşça geçersiniz).
Yan etkisi olmayan basit ayarlayıcı / alıcı yöntemlerini birim test etmiyorum. Ama diğer herkese açık yöntemleri test ediyorum. Algoritmalarımdaki tüm sınır koşulları için testler oluşturmaya ve birim testlerimin kapsamını kontrol etmeye çalışıyorum.
Çok iş var ama bence buna değer. Bir hata ayıklayıcıda kod yazmak yerine kod yazmayı (hatta test kodunu) tercih ederim. Kod oluşturma-dağıtma-hata ayıklama döngüsünü çok zaman alıcı buluyorum ve yapıma entegre ettiğim birim testleri ne kadar kapsamlı olursa, o kod oluşturma-dağıtma-hata ayıklama döngüsünden geçerken o kadar az zaman harcıyorum.
Neden mimariyi kodladığınızı da söylemediniz. Ama Java ben kullanım için Maven 2 , JUnit , DbUnit , cobertura , & EasyMock .
Hakkında ne kadar çok okursam, bazı birim testlerinin tıpkı kalıplara benzediğini düşünüyorum: Yetersiz dil kokusu.
Önemsiz toplayıcınızın gerçekten doğru değeri döndürüp döndürmediğini test etmeniz gerektiğinde, bunun nedeni alıcı adını ve üye değişken adını birbirine karıştırabilmenizdir. Ruby'nin 'attr_reader: name' adını girin ve bu artık olamaz. Sadece java'da mümkün değil.
Eğer sizin alıcı hiç nontrivial alır hala sonra bunun için bir test ekleyebilirsiniz.
Sizi endişelendiren kaynak kodunu test edin.
Hata yapmadığınız sürece, kendinizden çok emin olduğunuz kod bölümlerini test etmek yararlı değildir.
Bir hatayı ilk ve son kez düzeltmek için hata düzeltmelerini test edin.
Bilgi oluşturabilmeniz için belirsiz kod bölümlerinin güvenini kazanmak için test edin.
Mevcut özellikleri bozmamak için ağır ve orta düzeyde yeniden düzenlemeden önce test edin.
Bu cevap, kritikliği / önemi nedeniyle birim testi yapmak istediğinizi bildiğiniz belirli bir yöntem için kaç birim test kullanacağınızı bulmak için daha fazladır. McCabe'nin Temel Yol Testi tekniğini kullanarak , basit "ifade kapsamı" veya "şube kapsamı" na kıyasla niceliksel olarak daha iyi kod kapsamı güvenine sahip olmak için aşağıdakileri yapabilirsiniz: