TDD Sahte arama doğrulama - bir anti-desen mi?

TDD'yi yıllardır yapıyorum, kendimi çok iyi hissediyorum, test takımlarımı ve hepsini seviyorum. Ancak son zamanlarda çok fazla sahte arama doğrulaması yaptığımı fark ettim. Örneğin, bir Depoya enjekte edilecek bir Hizmetim olurdu - birim testimde Havuzun bir kopyasını geçip test ettiğim yöntem içinde çağrıldığını doğrularım. Daha sonra geri gönderilen sonuçların doğru olup olmadığını kontrol ederim (başka bir testte). Birim testlerim uygulama detaylarıyla çok bağlantılı olduğundan bu kesinlikle "yanlış" hissettiriyor. "Davranış" ı test etmeniz gerektiğini duydum, ancak birçok durumda ... emm - mümkün değil mi? Eğer birvoidÖrneğin, genellikle yan etkileri test edersiniz. Yani devam etmek ve bunun gösterilebileceği bazı basit kod-kata'ları göstermek kolaydır, ancak IMHO yazdığımız gerçek dünya programlarına pek iyi yansımaz. Yaptığım yanlış mı? Bu tür testler bir çeşit anti-desen midir? Bu konudaki fikrinizi takdir ediyorum, TDD söz konusu olduğunda hala biraz acemi.

Girişleri ve çıkışları test etmeye çalışmalısınız. Harici olarak görünen davranışı doğrulamalısınız. Sınıfınızın yaptığı "vaatler" veya "sözleşme".

Aynı zamanda bazen bir yöntemi test etmenin söylediklerinizi yapmaktan daha iyi bir yolu yoktur.

Testinizi daha kırılgan hale getirdiğini düşünüyorum, bu yüzden mümkünse uygulama ayrıntılarına dayanan testlerden kaçınmalısınız, ancak bu bir ya hep ya hiç anlaşma değil. Bazen sorun yok, gerçekleşen en kötü şey uygulamayı değiştirmeniz ve testi güncellemenizdir.

Bir testin amacı olası üretken uygulamaları kısıtlamaktır. Yalnızca gerçekten ihtiyacınız olan uygulamaya kısıtlamalar koyduğunuzdan emin olun. Tipik olarak bu programın yapması gereken şeydir , nasıl yaptığından değil .

Bu nedenle, örneğin hizmetiniz veri havuzuna bir şey eklerse, yeni girdinin daha sonra depoda bulunduğunu ve ekleme eyleminin tetiklendiğini test etmemelisiniz.

Bunun işe yaraması için, hizmetin testinde depo uygulamasını (başka yerde test edilmiş) kullanabilmeniz gerekir. Bir işbirlikçinin gerçek uygulamasını kullanmanın genellikle iyi bir yaklaşım olduğunu buldum - çünkü gerçekten en iyi uygulama.

"Peki ama testte gerçek uygulamaları kullanmak pahalıysa (örneğin, kurulumu karmaşık olan kaynaklara ihtiyaç duydukları için)? Bu durumda alay kullanmam gerekiyor, değil mi?"

Her durumda, gerçek uygulamaların birlikte çalıştığını test eden bir entegrasyon testi isteyeceksiniz. Bu tek bir entegrasyon testinin, hizmetinizi test etmek için gereken tek şey olduğundan emin olun. Veya başka bir deyişle: Bir hizmet çok sayıda ortak çalışanı birbirine bağlarsa (ve dolayısıyla test edilmesi güçse), herhangi bir mantık içermediğinden emin olun. Varsa ve birden fazla (entegrasyon) teste ihtiyacınız varsa, örneğin mantığı izole ederek ve daha test edilebilir hale getirerek kodunuzun yapısını değiştirmeniz gerekir.

Bu durumda alayları kullanmak, kötü izole edilmiş bir mantık parçasını test etmenin acısını hafifletir ve böylece bir mimari sorunu gizler . Bu nedenle, kötü yapılandırılmış kodu test etmek için alay kullanmayın, bunun yerine yapıyı düzeltin.

Düşüncelerim: 'toplu hizmetler'.

Çağrı doğrulama bunu yapar, ancak fazla değer sağlamaz. Sadece kablolarını kontrol ediyorsun.

Bunun için özel olmayan 3 farklı yol vardır:

1. Her bir hizmet için sahip olduğunuz testleri daha yüksek düzey davranışını kontrol edecek şekilde genişletin. Örneğin, birim testlerinizde bir bellek içi veritabanına isabet ediyorsanız, hizmeti bir seviyeye taşıyın, böylece hizmeti gerçek bir db'ye karşı test edersiniz. Hizmet katmanı soyutlama ağacının yukarısındadır ve testiniz de öyle olmalıdır.

2. Hizmeti doğrudan birleştirilmiş hizmetlerden oluşturmak için kod oluşturma özelliğini kullanın.

3. Aynı şeyi yapmak için bir tür yansıma veya dinamik dil kullanın. Örneğin, Java'da çağrıyı doğrudan ileten harika bir arayüz kullanmak mümkün olabilir.

Muhtemelen bunu yapmanın başka yolları vardır, ancak sadece kablolamayı kontrol etmek çok düşük geri ödeme yapar ve sizi bu uygulamaya zorlar.