TDD kullanarak ilk API hakkını nasıl alabilirim?

TDD'deki ilk denemelerimde bu oldukça aptalca bir soru olabilir. Getirdiği güven duygusunu ve genel olarak kodumun daha iyi yapısını sevdim, ancak tek sınıf oyuncak örneklerinden daha büyük bir şeye uygulamaya başladığımda zorluklarla karşılaştım.

Diyelim ki bir tür kitaplık yazıyorsunuz. Ne yapması gerektiğini biliyorsunuz, nasıl uygulanacağının genel bir yolunu biliyorsunuz (mimari olarak), ancak kodlarken genel API'nızda değişiklik yapmanız gereken "keşfetmeye" devam ediyorsunuz. Belki de bu özel yöntemi strateji modeline dönüştürmelisiniz (ve şimdi testlerinizde alaycı bir stratejiyi geçmeniz gerekiyor), belki de burada ve orada bir sorumluluğu yanlış yerleştirdiniz ve mevcut bir sınıfı bölüyorsunuz.

Mevcut kod üzerinde geliştirdiğinizde, TDD gerçekten iyi bir uyum gibi görünüyor, ancak her şeyi sıfırdan yazarken, testler yazdığınız API, büyük bir tasarım yapmazsanız biraz "bulanık" olur. İmzası (ve bu kısım için davranış) değişmiş olan yöntem üzerinde zaten 30 testiniz varsa ne yaparsınız? Bu, toplandıktan sonra değiştirmek için çok fazla testtir.

Ne demek "büyük tasarım ön" ben "sınıf mimarinizin mantıklı planlama " diyorum .

Birim testlerinden bir mimari geliştiremezsiniz. Bob Amca bile bunu söylüyor.

Eğer mimariyi düşünmüyorsanız, bunun yerine yaptığınız şey mimariyi görmezden gelip testleri bir araya getirip geçmelerini sağlıyorsa, binanın ayakta kalmasına izin verecek olan şeyi yok edersiniz çünkü sistemin yapısı ve sistemin yapısal bütünlüğünü korumaya yardımcı olan sağlam tasarım kararları.

http://s3.amazonaws.com/hanselminutes/hanselminutes_0171.pdf , Sayfa 4

TDD'ye yapısal tasarımınızı doğrulama perspektifinden yaklaşmanın daha mantıklı olacağını düşünüyorum . Test etmezseniz tasarımın yanlış olduğunu nasıl anlarsınız? Orijinal testleri değiştirmeden değişikliklerinizin doğru olduğunu nasıl doğrularsınız?

Yazılım tam olarak değişime tabi olduğu için "yumuşak" tır. Değişiklik miktarından rahatsızsanız , mimari tasarım konusunda deneyim kazanmaya devam edin ve uygulama mimarilerinizde yapmanız gereken değişikliklerin sayısı zamanla azalacaktır.

TDD yaparsanız. İmza ve davranışı testlerle yönlendirmeden değiştiremezsiniz. Böylece başarısız olan 30 test ya süreç içinde silinmiş ya da kodla birlikte değiştirilmiş / yeniden düzenlenmiştir. Ya da artık eskimiş, silinmesi güvenli.

Kırmızı-yeşil-refactor döngünüzde 30 kat kırmızıyı görmezden gelemez misiniz?

Testleriniz, üretim kodunuz boyunca yeniden düzenlenmelidir. Ödeyebiliyorsanız, her değişiklikten sonra tüm testleri yeniden çalıştırın.

TDD testlerini silmekten korkmayın. Bazı testler, istenen bir sonuca ulaşmak için yapı taşlarını test eder. İşlevsel düzeyde istenen sonuç önemli olan şeydir. Seçtiğiniz / icat ettiğiniz algoritmada ara adımların etrafındaki testler, sonuca ulaşmak için birden fazla yol olduğunda veya başlangıçta çıkmaz sokakla karşılaştığınızda çok değerli olabilir veya olmayabilir.

Bazen bazı iyi entegrasyon testleri oluşturabilir, bunları saklayabilir ve gerisini silebilirsiniz. Biraz içten dışa veya yukarıdan aşağıya çalışmanıza ve ne kadar büyük adımlar attığınıza bağlıdır.

Robert Harvey'in dediği gibi, muhtemelen farklı bir kavramsal araç tarafından kullanılması gereken bir şey için TDD'yi kullanmaya çalışıyorsunuz (yani: "tasarım" veya "modelleme").

Sisteminizi oldukça soyut ("genel", "belirsiz") bir şekilde tasarlamaya (veya "model") almaya çalışın. Örneğin, bir araba modellemeniz gerekiyorsa, startEngine () ve int koltuklar gibi bazı belirsiz yöntem ve alanlara sahip bir araba sınıfına sahip olmanız yeterlidir. Yani: nasıl uygulamak istediğinizi değil , halka ne göstermek istediğinizi açıklayın . Sadece temel işlevleri (okuma, yazma, başlatma, durdurma vb.) Göstermeye çalışın ve istemci kodunu üzerinde ayrıntılı olarak bırakın (preparMyScene (), killTheEnemy (), vb.).

Bu basit genel arayüzü varsayarak testlerinizi yazın.

Sınıflarınızın ve yöntemlerinizin iç davranışını, ihtiyacınız olduğunda değiştirin.

Genel arayüzünüzü ve test takımınızı değiştirmeniz gerektiğinde ve ne zaman durursanız, durun ve düşünün. Büyük olasılıkla bu, API'nizde ve tasarımınızda / modellemenizde yanlış bir şey olduğunu gösteren bir işarettir.

Bir API'yi değiştirmek olağandışı değildir. 1.0 sürümlerindeki çoğu sistem, programcıları / kullanıcıları API'larındaki olası değişikliklere karşı açıkça uyarır. Buna rağmen, sürekli, kontrolsüz bir API değişiklikleri akışı, kötü (veya tamamen eksik) tasarımın açık bir işaretidir.

BTW: Genellikle yöntem başına bir avuç test yaptırmalısınız. Bir yöntem, tanım gereği, bir tür veri üzerinde açıkça tanımlanmış bir "eylem" uygulamalıdır. Mükemmel bir dünyada, bu tek bir teste karşılık gelen tek bir eylem olmalıdır. Gerçek dünyada, aynı eylemin birkaç farklı "versiyonuna" ve birkaç farklı karşılık gelen teste sahip olmak olağandışı (ve yanlış değil) değildir. Elbette, aynı yöntem üzerinde 30 testten kaçınmalısınız. Bu, yöntemin çok fazla yapmaya çalıştığının açık bir işaretidir (ve dahili kodu kontrol dışıdır).

Buna kullanıcının bakış açısından bakıyorum. Örneğin, API'larınız ad ve yaş ile bir Person nesnesi oluşturmama izin veriyorsa, ad ve yaş için bir Kişi (dize adı, int age) oluşturucusu ve erişimci yöntemleri olsaydı daha iyi olurdu. Adı ve yaşı olmayan ve olmayan yeni Kişiler için test senaryoları oluşturmak kolaydır.

Doug