TDD, savunma programlamasını gereksiz kılıyor mu?

Bugün bir meslektaşımla ilginç bir tartışma yaptım.

Ben bir savunma programcısıyım. " Bir sınıfın nesnelerinin sınıf dışından etkileşime girdiğinde geçerli bir duruma sahip olmasını sağlamalı " kuralının her zaman uyulması gerektiğine inanıyorum. Bu kuralın nedeni, sınıfın kullanıcılarının kim olduğunu bilmemesi ve yasadışı bir şekilde etkileşime girdiğinde tahminen başarısız olması gerektiğini bilmesidir. Bence bu kural tüm sınıflar için geçerli.

Bugün bir tartışmamın olduğu belirli bir durumda, kurucumun argümanlarının doğru olduğunu doğrulayan bir kod yazdım (örn. Bir tamsayı parametresi> 0 olmalıdır) ve ön koşul yerine getirilmezse bir istisna atılır. Öte yandan meslektaşım, böyle bir kontrolün gereksiz olduğuna inanıyor çünkü ünite testleri sınıfın herhangi bir yanlış kullanımını yakalayabiliyor. Ek olarak, savunma programlaması doğrulamalarının da ünite testine tabi tutulması gerektiğine inanıyor, bu nedenle savunma programlaması çok iş katıyor ve bu nedenle TDD için uygun değil.

TDD'nin savunma programlamasını değiştirebileceği doğru mu? Sonuç olarak parametre doğrulama (ve kullanıcı girişi demek istemiyorum) gereksiz mi? Yoksa iki teknik birbirini tamamlıyor mu?

Saçma. TDD, kodları testleri geçmeye zorlar ve tüm kodu, çevresinde bazı testler yapmaya zorlar. Tüketicilerinizin yanlış kod çağırmasını engellemez, ayrıca programcıların eksik test durumlarını sihirli bir şekilde engellemez.

Hiçbir metodoloji kullanıcıları kodu doğru şekilde kullanmaya zorlayamaz.

Orada ise Çeki ekleyerek muhtemelen tarafından - Eğer mükemmel TDD Bilseydin önce bunu uygulamak için bir test ihtimaline karşı> 0 çek dinledim ve bu ele olurdu yapılacak hafif bir argüman. Ancak TDD yaptıysanız, gereksiniminiz (yapıcıdaki> 0) ilk önce başarısız olan bir test çantası olarak görünür. Böylece çekinizi ekledikten sonra size testi veriyoruz.

Bazı savunma koşullarının test edilmesi de mantıklıdır (mantık eklediniz, neden bu kadar kolay test edilebilir bir şeyi test etmek istemiyorsunuz?). Neden buna katılmıyor göründüğünden emin değilim.

Yoksa iki teknik birbirini tamamlıyor mu?

TDD testleri geliştirecek. Parametre validasyonu uygulamak onları pasif hale getirecektir.

Savunma programlaması ve birim testleri, hataları yakalamanın iki farklı yoludur ve her birinin farklı güçleri vardır. Yalnızca hataları tespit etmenin bir yolunu kullanmak, hata tespit mekanizmalarınızı kırılgan hale getirir. Her ikisini de kullanmak, herkesin karşı karşıya kaldığı bir API olmayan kodda bile, bir başkası tarafından kaçırılmış olabilecek hataları yakalayacaktır; örneğin, birileri genel API’ye geçirilen geçersiz veriler için bir birim testi eklemeyi unutmuş olabilir. Her şeyi uygun yerlerde kontrol etmek, hatayı yakalamak için daha fazla şans demektir.

Bilgi güvenliğinde buna Derinlikli Savunma denir. Birden fazla savunma katmanına sahip olmak, birinin başarısız olması durumunda, onu yakalayacak başkalarının da olmasını sağlar.

Sen: İş arkadaşınız bir konuda haklı gerektiğini sizin doğrulamaları test etmek, ancak bu "gereksiz iş" değildir. Diğer kodları test etmekle aynıdır, tüm kullanımların, hatta geçersiz olanların bile beklenen bir sonuç aldığından emin olmak istersiniz.

TDD kesinlikle savunma programlamasının yerini almaz. Bunun yerine, tüm savunmanın yerinde olduğundan ve beklendiği gibi çalıştığından emin olmak için TDD'yi kullanabilirsiniz.

TDD'de, ilk önce bir test yazmadan kod yazmanız gerekmez - kırmızı-yeşil-refactor döngüsünü dini olarak izleyin. Bu, doğrulama eklemek istiyorsanız, önce bu doğrulamayı gerektiren bir test yazın. Söz konusu yöntemi negatif sayılarla ve sıfırla çağırın ve bir istisna atmasını bekleyin.

Ayrıca “refactor” basamağını da unutmayın. TDD test-iken tahrik , bu test-anlamına gelmez sadece . Yine de uygun tasarımı uygulamanız ve makul bir kod yazmanız gerekir. Savunma kodu yazmak, mantıklı bir koddur, çünkü beklentileri daha belirgin hale getirir ve kodunuz genel olarak daha sağlamdır - olası hataları erken tespit etmek onların hata ayıklamasını kolaylaştırır.

Fakat hataları bulmak için testler kullanmamız gerekmiyor mu? Beyanlar ve testler tamamlayıcıdır. İyi bir test stratejisi , yazılımın sağlam olduğundan emin olmak için çeşitli yaklaşımları bir araya getirir. Yalnızca ünite testi veya yalnızca entegrasyon testi veya yalnızca koddaki iddiaların tümü tatmin edici değil, yazılımınıza kabul edilebilir bir gayretle yeterli bir güven derecesine ulaşmak için iyi bir kombinasyona ihtiyacınız var.

Öyleyse, iş arkadaşınızla ilgili çok büyük bir kavramsal yanlış anlama vardır: Ünite testleri sınıfınızın kullanımlarını asla test edemez , yalnızca sınıfın kendisinin izolasyonda beklendiği gibi çalıştığını gösterir. Çeşitli bileşenlerin arasındaki etkileşimin işe yarayıp yaramadığını kontrol etmek için entegrasyon testlerini kullanırsınız, ancak olası test durumlarının birleşik patlaması her şeyi test etmeyi imkansız hale getirir. Entegrasyon testleri bu nedenle kendilerini birkaç önemli durumla sınırlandırmalıdır. Kenar vakalarını ve hata durumlarını da kapsayan daha ayrıntılı testler birim testleri için daha uygundur.

Savunma programlamasını desteklemek ve sağlamak için testler yapıldı

Defansif programlama, çalışma zamanında sistemin bütünlüğünü korur.

Testler (çoğunlukla statik) teşhis araçlarıdır. Çalışma zamanında, testleriniz görünürde hiçbir yerde değildir. Yüksek tuğladan bir duvar veya bir kaya kubbesi koymak için kullanılan iskele gibiler. Yapının dışında önemli parçalar bırakmazsınız, çünkü inşaat sırasında ayakta tutan bir iskeleye sahipsiniz. Tüm önemli parçaların yerleştirilmesini kolaylaştırmak için inşaat sırasında dayanan bir iskeleye sahipsiniz .

EDIT: Bir benzetme

Koddaki yorumlardaki analoji ne olacak?

Yorumların amacı vardır, ancak fazlalık olabilir, hatta zararlı olabilir. Örneğin, yorumlar hakkında kodla ilgili temel bilgileri içeri koyarsanız, kodu değiştirin, yorumlar en iyi ihtimalle alakasız ve en kötüsü zararlı olur.

Demek ki, kod tabanınızla ilgili birçok gerçek bilgiyi, TestA gibi testlerden geçirmeyin, ki bu yöntem boş bırakamaz ve MethodB'nin argümanı olmalıdır > 0. Sonra kod değişir. Şimdi A için null tamamdır ve B, -10 kadar küçük değerler alabilir. Mevcut testler artık işlevsel olarak yanlış, ancak geçmeye devam edecek.

Evet, kodu güncellerken testleri de güncellemelisiniz. Ayrıca kodu güncellerken yorumları da güncellemeniz (veya kaldırmanız) gerekir. Ama hepimiz biliyoruz ki bu şeyler her zaman olmaz ve bu hatalar yapılır.

Testler sistemin davranışını doğrular. Bu gerçek davranış, testlerin kendine özgü değil , sistemin kendisine özgüdür.

Ne yanlış gidebilir ki?

Testlerle ilgili amaç, yanlış olabilecek her şeyi düşünmek, doğru davranışı kontrol eden bir test yazmak ve ardından çalışma zamanı kodunu oluşturmak ve böylece tüm testleri geçmektir.

Bu, savunma programlamasının noktası olduğu anlamına gelir .

TDD sürücüleri testler kapsamlı olursa, savunma programlama.

Daha fazla test, daha savunucu programlama

Hatalar kaçınılmaz olarak bulunduğunda, hatayı gösteren koşulları modellemek için daha fazla test yazılır. Ardından kod, bu testleri geçmek için kodla sabitlenir ve yeni testler test odasında kalır.

İyi bir test seti, hem iyi hem de kötü argümanları bir işleve / yönteme aktaracak ve tutarlı sonuçlar bekleyecektir. Bu da, test edilen bileşenin kendisine iletilen argümanları onaylamak için önkoşul kontrolleri (savunma programlaması) kullanacağı anlamına gelir.

Genel olarak konuşursak ...

Örneğin, belirli bir prosedür için boş bir argüman geçersizse, en az bir test boş geçecek ve bir tür "geçersiz boş argüman" istisnası / hatası bekleyecek.

En az bir başka test elbette geçerli bir argüman geçirecek - ya da büyük bir diziden geçecek ve on beş geçerli argüman geçecek - ve ortaya çıkan durumun uygun olduğunu onaylayacaktır.

Bir sınama , bu boş argümanı geçmezse ve beklenen istisna ile tokatlanırsa (ve bu istisna, kodun kendisine iletilen durumu savunmacı bir şekilde kontrol ettiği için atıldı), o zaman boş bir sınıfın özelliğine atanmış veya gömülmüş olabilir Olmaması gereken bir tür koleksiyonda.

Bu , yazılım gönderildikten sonra, sınıfın geçtiği sistemin tamamen farklı bir bölgesinde, bazı uzak coğrafi yerel ayarlarda beklenmeyen davranışlara neden olabilir . Ve bu aslında kaçınmaya çalıştığımız bir şey, değil mi?

Daha da kötüsü olabilirdi. Geçersiz durumda olan sınıf örneği yalnızca daha sonra kullanılmak üzere sulandırıldığında bir arızaya neden olmak için serileştirilebilir ve saklanabilir. Tanrım, bilmiyorum, belki bir kapatma işleminden sonra yeniden başlatılamayan bir tür mekanik kontrol sistemidir, çünkü kendi kalıcı konfigürasyon durumunu seri hale getiremez. Veya sınıf örneği seri hale getirilebilir ve başka bir varlık tarafından oluşturulan tamamen farklı bir sisteme geçirilebilir ve bu sistem çökebilir.

Özellikle diğer sistemin programcıları savunmada kodlamadıysa.

TDD'nin yerine genel olarak “yazılım testi” ve genel olarak “savunma programlaması” yerine, genel olarak “savunma programlaması” yerine, iddiaları kullanan savunma programlarının en sevdiğim yöntemlerinden bahsedelim.

Bu yüzden, yazılım testi yaptığımızdan, üretim beyannamesi üzerinde açıklayıcı ifadeler bırakmayı bırakmalıyız, değil mi? Bunun yanlış olduğu yolları saymama izin verin:

1. İddialar isteğe bağlıdır, bu nedenle beğenmezseniz, sadece iddialarınızı devre dışı bırakarak sisteminizi çalıştırın.

2. İddialar testlerin yapamayacağı şeyleri kontrol eder (ve etmemelidir.) Çünkü testler sisteminizin kara kutu görüntüsüne sahip olması gerekirken, iddialar beyaz kutu görünümündedir. (Elbette, içinde yaşadıkları için.)

3. İddialar mükemmel bir dokümantasyon aracıdır. Hiç bir yorum, aynı şeyi iddia eden bir kod parçası kadar net değildi veya hiç olmayacaktı. Ayrıca, dokümantasyon kod geliştikçe modası geçmiş olma eğilimindedir ve hiçbir şekilde derleyici tarafından uygulanabilir değildir.

4. Beyanlar test kodundaki hataları yakalayabilir. Hiç bir testin başarısız olduğu bir duruma rastladınız mı ve kimin yanlış olduğunu bilmiyorsunuz - üretim kodu veya test?

5. İddialar testten daha uygun olabilir. Testler, işlevsel gereksinimler tarafından öngörülenleri kontrol eder, ancak kodun genellikle bundan daha teknik olan bazı varsayımlarda bulunması gerekir. İşlevsel gereksinim belgeleri yazan insanlar nadiren sıfıra bölünmeyi düşünürler.

6. İddialar, sadece geniş çapta ipuçlarını test eden hataları belirtir. Bu nedenle, testiniz bazı önkoşulları belirler, uzun bir kod parçası çağırır, sonuçları toplar ve beklendiği gibi olmadığını bulur. Yeterli sorun giderme verildiğinde sonuçta olayların yanlış gittiği yeri tam olarak bulacaksınız, ancak iddialar genellikle önce onu bulacaktır.

7. İddialar programın karmaşıklığını azaltır. Yazdığınız her kod satırı programın karmaşıklığını arttırır. İddialar ve final( readonly) anahtar sözcüğü, program karmaşıklığını azalttığını bildiğim tek iki yapıdır. Bu paha biçilmez.

8. İddialar, derleyicinin kodunuzu daha iyi anlamasını sağlar. Lütfen bunu evde deneyin: void foo( Object x ) { assert x != null; if( x == null ) { } }derleyiciniz, durumun x == nulldaima yanlış olduğunu söyleyen bir uyarı vermelidir . Bu çok faydalı olabilir.

Yukarıdakiler, blogumdaki bir yazının özeti, 2014-09-21 "Beyanlar ve Testler"

Yanıtların çoğunun kritik bir ayrım eksik olduğuna inanıyorum: Kodunuzun nasıl kullanılacağına bağlı.

Söz konusu modül, test ettiğiniz uygulamanın bağımsızlığından başka müşteriler tarafından kullanılacak mı? Üçüncü tarafların kullanması için bir kütüphane veya API sağlıyorsanız, kodunuzu yalnızca geçerli girdiyle çağırmalarını sağlayamazsınız. Tüm girişi doğrulamanız gerekir.

Ancak söz konusu modül yalnızca kontrol ettiğiniz kod tarafından kullanılıyorsa, arkadaşınızın bir noktası olabilir. Söz konusu modülün yalnızca geçerli girişle çağrıldığını doğrulamak için birim sınamalarını kullanabilirsiniz. Ön koşul kontrolleri hala iyi bir uygulama düşünülebilir, ama bir trade-off: Sana çöp Eğer durum için kontrol eden kod biliyorum ortaya asla, sadece kodların amaçlarını örtmektedir.

Önkoşul kontrollerinin daha fazla birim testi gerektirdiğini kabul etmiyorum. Bazı geçersiz giriş biçimlerini test etmeniz gerekmediğine karar verirseniz, işlevin önkoşul denetimleri içerip içermediği önemli değildir. Testlerin uygulama detaylarını değil davranışları doğrulaması gerektiğini unutmayın.

Bu argüman beni şaşırtıyor, çünkü TDD'yi uygulamaya başladığımda "nesne" şeklindeki birim testleri <geçersiz girdi> "2 veya 3 kat arttığında yanıt veriyor. Meslektaşınızın, bu tür birim testlerini başarılı bir şekilde, işlevleri doğrulanmadan başarılı bir şekilde geçmeyi nasıl başardığını merak ediyorum.

Bunun bir sonucu olarak, diğer testlerin argümanlarına aktarılacak kötü çıktılar üretmediğinizi gösteren sohbet durumu ispatlanması çok daha zor. İlk durumda olduğu gibi, bu durum büyük ölçüde kapsamlı vakaların kapsamına bağlıdır, ancak tüm işlev girişlerinizin, üniteyi çıktılarını test etmiş ve kullanıcı girişinden değil, test ettiği diğer işlevlerin çıktılarından gelmesi gerekliliğine ek gereksiniminiz vardır. üçüncü parti modülleri.

Başka bir deyişle, TDD'nin yaptığı şey, unutmaktan kaçınmanıza yardımcı olmak için doğrulama koduna ihtiyaç duymanızı engellemez .

Sanırım meslektaşınızın sözlerini cevapların çoğundan farklı olarak yorumluyorum.

Bana öyle geliyor ki tartışmanın:

• Tüm kodlarımız birim test edildi.
• Bileşeninizi kullanan tüm kod bizim kodumuzdur veya birim başkası tarafından test edilmemişse (açıkça belirtilmemiş, ancak şunu anlıyorum "birim testleri sınıfın yanlış kullanımını yakalamalıdır").
• Bu nedenle, işlevinizin her arayanı için, bileşeninizi alay eden bir yerde bir birim testi vardır ve arayan, bu alay için geçersiz bir değer geçirirse test başarısız olur.
• Bu nedenle, geçersiz bir değer iletildiğinde işlevinizin ne yaptığı önemli değildir, çünkü testlerimiz bunun gerçekleşmeyeceğini söylüyor.

Bana göre, bu argüman buna mantıklı geliyor, ancak olası her durumu kapsayacak şekilde birim testlerine çok fazla güveniyor. Basit gerçek şu ki,% 100 çizgi / dal / yol kapsama alanının , arayan tarafın geçebileceği her değeri zorunlu olarak uygulamaması , oysa arayanın olası tüm durumlarının% 100'ünü kapsaması (yani, girdilerinin tüm olası değerleri) ve değişkenler) hesaplamalı olarak mümkün değildir.

Bu nedenle, (testler devam ettiği sürece) hiçbir zaman hatalı değerler geçmemelerini ve ek olarak, bileşeninizin kötü bir değer iletildiğinde tanınabilir bir şekilde başarısız olmasını sağlamak için arayanları birim sınamasına tercih etme eğiliminde olurum . en azından tercih ettiğiniz dilde kötü değerleri tanımanız mümkün olduğu sürece). Bu, entegrasyon testlerinde problemler ortaya çıktığında hata ayıklamaya yardımcı olacak ve benzer şekilde sınıfınızın kod birimlerini bu bağımlılıktan izole etmede daha az titiz olan kullanıcılarına da yardımcı olacaktır.

Ancak, <= 0 değeri iletildiğinde işlevinizin davranışını belgeleyip test ederseniz, negatif değerlerin artık geçersiz olmadığına (en azından, hiçbir şekilde herhangi bir argümandan daha fazla geçersiz olmayacağına) throwdikkat edin. bir istisna atmak için de belgelenmiştir!). Arayanlar bu savunma davranışına güvenme hakkına sahiptir. Fonksiyonu - Dil bu her durumda en iyi senaryo olduğunu olabilir, olabilir izin vardır hayır "geçersiz girdileri", ama birim test yeterince olması gereken bir durum atma içine işlevini tahrik etmemeye bekliyoruz arayanlar onlar don sağlamak için' t Buna sebep olan değerleri geçmeyin.

Meslektaşınızın çoğu cevaptan biraz daha az yanlış olduğunu düşünmeme rağmen, aynı sonuca ulaşıyorum, ki bu iki teknik birbirini tamamlıyor. Savunma programlayın, savunma kontrollerinizi belgeleyin ve test edin. İş, yalnızca "gereksizdir", kodunuzun kullanıcıları hata yaptıklarında yararlı hata mesajlarından yararlanamazlarsa. Teoride, bütün kodları kendinizle bütünleştirmeden önce bütün kodlarını sınarlarsa ve testlerinde hiçbir zaman hata olmazsa, o zaman hata mesajlarını asla görmezler. Uygulamada TDD ve toplam bağımlılık enjeksiyonunu yapsalar bile, geliştirme sırasında hala araştırma yapabilirler veya testlerinde atlamalı olabilirler. Sonuç olarak, kodları mükemmel olmadan önce kodunuzu ararlar!

Genel arayüzler kötüye kullanılabilir ve kullanılabilir

İş arkadaşınızın "ünite testlerinin, sınıfın herhangi bir yanlış kullanımını yakalaması gerektiği" iddiası, özel olmayan herhangi bir arayüz için kesinlikle yanlıştır. Eğer bir public işlev tamsayı argümanlarıyla çağrılabilirse, o zaman herhangi bir tamsayı argümanıyla çağrılabilir ve çağrılabilir ve kod uygun şekilde davranmalıdır. Genel işlev imzası örneğin Java Double tipini kabul ederse, null, NaN, MAX_VALUE, -Inf hepsi olası değerlerdir. Senin birimin testler Bu testler bu sınıfı kullanır kodu test edemezsiniz çünkü bu kod henüz yazılmaz, çünkü sınıfın yanlış kullanımları yakalayamaz sizin tarafından yazılmış olabilir ve kesinlikle kapsamı dışında olacak senin birim testler .

Öte yandan, bu yaklaşım (umarım çok daha fazla sayıda) özel mülk için geçerli olabilir - eğer bir sınıf bazı gerçeklerin daima doğru olmasını sağlayabilirse (örneğin, özellik X hiç boş olamaz, tamsayı konumu maksimum uzunluğu aşmaz) A işlevi çağrıldığında, tüm önkoşul veri yapıları iyi oluşturulmuştur) o zaman bunu performans nedenleriyle tekrar tekrar doğrulamaktan kaçınmak ve bunun yerine birim testlerine güvenmek uygun olabilir.

Kötüye kullanıma karşı savunma , bir gereklilik nedeniyle geliştirilen bir özelliktir . (Tüm arayüzler kötüye kullanıma karşı sıkı kontroller gerektirmez; örneğin, çok dar kullanılan iç üniteler)

Bu özellik test gerektiriyor: kötüye kullanıma karşı savunma gerçekten işe yarıyor mu? Bu özelliği test etmenin amacı, bunu yapmadığını göstermeye çalışmaktır: çekleri tarafından yakalanmayan bir modülün yanlış kullanımına ulaşmak.

Özel kontroller gerekli bir özellik ise, bazı testlerin varlığının onları gereksiz kıldığını iddia etmek gerçekten de saçmadır. Parametre üç negatif olduğunda (diyelim) bir istisna atan bazı fonksiyonların bir özelliği ise, pazarlık yapılamaz; Bunu yapacak.

Bununla birlikte, meslektaşınızın, girdiler üzerinde belirli kontroller için bir zorunluluk olmadığı, kötü girdiler için belirli cevaplar veren bir durumdan dolayı gerçekten mantıklı geldiğinden şüpheleniyorum : bunun için yalnızca anlaşılmış bir genel şart olduğu sağlamlık.

Bazı üst düzey fonksiyonlara giriş kontrolleri, kısmen, zayıf veya kötü bir şekilde test edilmiş dahili kodları beklenmeyen parametreler kombinasyonlarından korumak için (kod iyi bir şekilde test edilirse kontroller gerekli olmaz: kod sadece " hava durumu "kötü parametreler".

İş arkadaşının fikrinde gerçekler var ve muhtemelen ne anlama geldiği şudur: Savunak kodlu ve tüm kötüye kullanımlara karşı ayrı ayrı test edilen çok sağlam alt seviye parçalardan bir işlev geliştirirsek, daha üst düzey işlevlerin olması mümkündür. kendi kapsamlı kontrolleri olmadan sağlam.

Eğer sözleşmesi ihlal edilirse, belki istisnalar ya da her neyse, üst düzey işlevlerin kötüye kullanımı ile sonuçlanır.

Bununla ilgili tek sorun, alt seviye istisnalarının, üst seviye arayüze özgü olmamasıdır. Bunun bir problem olup olmadığı gereksinimlerin ne olduğuna bağlıdır. Gereklilik basitçe "işlev yanlış kullanıma karşı sağlam olmalı ve çarpmak yerine bir istisna atsın ya da çöp verileriyle hesaplamaya devam etsin" ise, o zaman aslında üzerinde bulunduğu alt seviye parçaların tüm sağlamlığı ile karşılanabilir. inşa edilmiş.

İşlev, parametreleriyle ilgili çok spesifik, ayrıntılı hata bildirimi için bir gereksinime sahipse, daha düşük seviye kontrolleri bu gereklilikleri tam olarak karşılamaz. Yalnızca fonksiyonun bir şekilde patlamasını sağlarlar (kötü bir parametre kombinasyonu ile devam etmez, çöp sonucu verir). İstemci kodu, belirli hataları yakalamak ve bunları gidermek için özel olarak yazılmışsa, düzgün çalışmayabilir. İstemci kodunun kendisi, girdi olarak, parametrelerin dayandığı verileri elde ediyor olabilir ve bunları kontrol etme ve hatalı değerleri belgelendiği gibi belirli hatalara çevirme işlevini bekliyor olabilir (böylece bunları ele alabilir. Hatalar)) Başka bir hatadan ziyade işlenmemiş ve yazılım görüntüsünü durduramaz.

TP; DR: Meslektaşınız muhtemelen aptal değildir; aynı şey etrafında sadece farklı bakış açılarıyla birbirinizden geçmiş gibi konuşuyorsunuz, çünkü gereksinimler tamamen çivilenmemiş ve her birinizin "yazılı olmayan gereksinimlerin" ne olduğu konusunda farklı bir fikri var. Parametre kontrolünde belirli bir gereklilik olmadığı zaman, zaten detaylı kontrol kodlaması yapmanız gerektiğini düşünüyorsunuz; Meslektaşım, parametreler yanlış olduğunda sağlam düşük seviye kodunun patlamasına izin verin. Kod aracılığıyla yazılı olmayan gereksinimler hakkında tartışmak verimsizdir: kod yerine gereksinimler konusunda hemfikir olmadığınıza dikkat edin. Kodlama şekliniz, gereksinimlerin ne olduğunu düşündüğünüzü yansıtır; meslektaşının yolu, gereksinimler hakkındaki görüşünü temsil eder. Bu şekilde görürseniz, doğru ya da yanlış olanın olmadığı açıktır. t kodunun kendisinde; Kod sadece şartnamenin ne olması gerektiği konusunda fikriniz için bir vekildir.

Testler, sınıf sözleşmenizi tanımlar.

Sonuç olarak , bir testin bulunmaması tanımsız davranış içeren bir sözleşmeyi tanımlar . Yani geçerken içinnullFoo::Frobnicate(Widget widget) ve anlatılmamış çalışma zamanı tahribat gelişir, kendi sınıfının sözleşme dahilinde devam etmektedir.

Daha sonra, mantıklı bir seçim olan “tanımsız davranış olasılığını istemiyoruz” kararını veriyorsunuz. Bu, geçebilmek nulliçin beklenen bir davranışın olması gerektiği anlamına gelirFoo::Frobnicate(Widget widget) .

Ve siz de bu kararı bir

[Test]
void Foo_FrobnicatesANullWidget_ThrowsInvalidArgument() 
{
    Given(Foo foo);
    When(foo.Frobnicate(null));
    Then(Expect_Exception(InvalidArgument));
}

İyi bir dizi test dıştan uygulayacaktır sınıfınızın arayüzünü kullanır ve bu tür yanlış kullanımların doğru tepki vermesini sağlar (bir istisna veya "doğru" olarak tanımladığınız şey). Aslında, bir sınıf için yazdığım ilk sınama durumu, yapıcısını aralık dışı argümanlarla çağırmaktır.

Tam olarak test edilmiş bir yaklaşımla ortadan kaldırılma eğiliminde olan savunma programlarının türü, harici kod tarafından ihlal edilemeyen dahili değişmezlerin gereksiz şekilde doğrulanmasıdır .

Bazen kullandığım faydalı bir fikir, nesnenin değişmezlerini test eden bir yöntem sağlamak; Yırtma yönteminiz, nesne üzerindeki dış eylemlerinizin değişmezleri asla kırmadığını doğrulamak için çağırabilir.

TDD'nin testleri kodun geliştirilmesi sırasında hatalar yakalayacaktır .

Defansif programlamanın bir parçası olarak tanımladığınız sınır kontrolü , kod kullanımı sırasında hatalar yakalayacaktır .

İki alan aynıysa, yazdığınız kod yalnızca bu özel proje tarafından yalnızca dahili olarak kullanılırsa, TDD'nin tanımladığınız savunma programlama sınırlarının gerekliliğini ortadan kaldıracağı, ancak yalnızca bu türleri Sınırların kontrolü TDD testlerinde özel olarak yapılır .

Spesifik bir örnek olarak, TDD kullanılarak bir finansal kod kütüphanesinin geliştirildiğini varsayalım. Testlerden biri, belirli bir değerin asla negatif olamayacağını iddia edebilir. Bu, kütüphanenin geliştiricilerinin, özellikleri uygularken sınıfları yanlışlıkla yanlış kullanmamalarını sağlar.

Ancak, kitaplık yayınlandıktan ve onu kendi programımda kullandıktan sonra, bu TDD testleri benden olumsuz bir değer atamamı engellemiyor (maruz kaldığını varsayarak). Sınır kontrolü yapar.

Benim demek olduğunu kod sadece hiç (TDD altında) daha büyük bir başvurunun gelişiminin bir parçası olarak dahili olarak kullanıldığı takdirde, diğer programcılar tarafından kullanılan bir kütüphane olacak eğer bir TDD assert, negatif değer sorunu çözmek olabilir iken TDD olmadan çerçeve ve testler , sınır kontrol konuları.

TDD ve savunma programlaması el ele gidiyor. Her ikisini de kullanmak gereksiz değil, aslında tamamlayıcıdır. Bir işleve sahip olduğunuzda işlevin açıklandığı gibi çalıştığından ve bunun için testler yazdığınızdan emin olmak istersiniz; Kötü bir giriş, kötü geri dönüş, kötü durum, vb. durumlarında ne olduğunu kapsamazsanız, testlerinizi yeterince sağlam bir şekilde yazmazsınız ve tüm testleriniz başarılı olsa bile kodunuz kırılgan olacaktır.

Gömülü bir mühendis olarak, birlikte iki byte eklemek ve sonucu şöyle döndürmek için bir işlev yazma örneğini kullanmaktan hoşlanıyorum:

uint8_t AddTwoBytes(uint8_t a, uint8_t b, uint8_t *sum); 

Şimdi sadece basitçe *(sum) = a + byapsaydınız işe yarar , ama sadece bazı girdilerle. a = 1ve b = 2yapacaktı sum = 3; Ancak, toplamın büyüklüğü bir bayt olduğundan a = 100ve taşma nedeniyle b = 200yapacağı için sum = 44. C'de, bu fonksiyonun başarısız olduğunu belirtmek için bu durumda hata döndürürsünüz; bir istisna atmak kodunuzda aynı şeydir. Başarısızlıkları göz önünde bulundurmamak veya bunları nasıl ele alacağınızı test etmek uzun süren işe yaramayacaktır, çünkü bu koşullar meydana gelirse, ele alınmayacak ve herhangi bir sayıda soruna neden olabilir.