Test odaklı geliştirme beni SOLID'yi takip etmeye zorluyor mu?

TDD uygulayıcılarından, TDD'nin avantajlarından birinin, geliştiricileri SOLID ilkelerini (Tek sorumluluk, Açık-kapalı, Liskov ikamesi, Arayüz ayrımı ve Bağımlılık dönüşümü) takip etmeye zorlaması olduğunu çok şey duydum . Ancak bana gelince, SOLID'i takip etmenin (ve böylece test edilebilir mimari yaratmanın) önemli olduğunu anlamak için sadece bazı testler (öncelikle birim test) yazmak yeterlidir.

TDD, geliştiricileri SOLID'i sadece birim testler yazmaktan daha aktif olarak takip etmeye zorluyor mu?

Her şeyden önce, TDD kesinlikle gelmez zorlamak KATI kod yazmak size. İsterseniz TDD yapabilir ve büyük bir karmaşa yaratabilirsiniz.

Tabii ki, SOLID ilkelerini bilmek yardımcı olur, çünkü aksi takdirde sorunlarınızın çoğuna iyi bir cevap vermeyebilir ve böylece kötü testlerle birlikte kötü kod yazabilirsiniz.

SOLID ilkelerini zaten biliyorsanız, TDD bunları düşünmenizi ve aktif olarak kullanmanızı teşvik edecektir.

Yani illa harflerin tamamı kapsamaz dedi KATI ama kuvvetle teşvik eder ve o kadar hemen görünür ve rahatsız edici yapmadığı sonuçlarını yapar, çünkü en azından kısmen KATI kod yazmak size teşvik etmektedir.

Örneğin:

1. İhtiyacınız olanı alay edebilmek için ayrıştırılmış kod yazmanız gerekir. Bu, Bağımlılık Ters Çevirme İlkesini destekler .
2. Açık ve kısa testler yazmanız gerekir, böylece testlerde çok fazla değişiklik yapmak zorunda kalmazsınız (aksi halde yapılırsa büyük bir kod gürültüsü kaynağı olabilir). Bu, Tek Sorumluluk İlkesini destekler .
3. Bu tartışılabilir, ancak Arayüz Segregasyon Prensibi , sınıfların alay etmeyi takip etmeyi ve anlamayı kolaylaştıran daha hafif arayüzlere bağımlı olmalarına izin verir, çünkü "Neden bu 5 yöntem de alay edilmedi?" daha da önemlisi, hangi yöntemin alay edileceğine karar verirken çok fazla seçeneğiniz yoktur. Test etmeden önce sınıfın tüm kodunu gerçekten gözden geçirmek istemiyorsanız ve nasıl çalıştığına dair temel bir anlayış elde etmek için deneme yanılma yöntemini kullanmak iyi bir şeydir.

Açık / Kapalı ilkesine uymak , koddan sonra yazılan testlere yardımcı olabilir , çünkü genellikle test edilen sınıflardan türeyen test sınıflarındaki harici hizmet çağrılarını geçersiz kılmanıza izin verir. TDD'de bunun diğer ilkeler kadar gerekli olmadığına inanıyorum, ama yanılmış olabilirim.

Sınıfınızın, aynı statik olarak yazılan arabirimi uygulayan desteklenmeyen bir örnek alması için değişiklikleri en aza indirmek istiyorsanız, ancak uygun test senaryolarında gerçekleşmesi olası değilse, Liskov ikame kuralına uymak harikadır. genellikle bağımlılıklarının gerçek dünyadaki uygulamalarını test altında herhangi bir sınıftan geçmeyecektir.

En önemlisi, daha temiz, daha anlaşılır ve bakımı kolay bir kod yazmanızı teşvik etmek için SOLID ilkeleri yapıldı ve TDD de öyle. Dolayısıyla, TDD'yi düzgün bir şekilde yaparsanız ve kodunuzun ve testlerinizin nasıl göründüğüne dikkat ederseniz (ve hemen geri bildirim, API ve doğruluk açısından akıllıca olduğunuz için çok zor değil), genel olarak SOLID ilkeleri hakkında daha az endişelenebilirsiniz.

Hayır

TDD, sürekli yeniden düzenleme nedeniyle iyi uygulamaları takip etmeyi kolaylaştırabilir, ancak sizi herhangi bir ilkeye uymaya zorlamaz. Tek yaptığı, yazdığınız kodun test edildiğinden emin olmaktır. Testi tamamlamak için kod yazarken istediğiniz ilkeleri takip edebilirsiniz; ya da hiç ilke yok.

TDD yapmaya başladığımda, SOLID Prensipleri konusundaki anlayışım genişledi. Bağımlılıkları nasıl taklit edeceğimizi düşünmeye başlar başlamaz, kod tabanındaki hemen hemen her bileşenin alternatif bir alternatif uygulamaya sahip olduğunu fark ettim. Ve basit bir genel API'yi test etmenin ne kadar kolay olduğu.

Ayrıca, çoğu tasarım deseninin çok daha güçlü bir şekilde anlaşılmasını sağlamıştır. Özellikle Strateji Paterni.

Evet : TDD temel olarak iyi bir tasarım tekniğidir (ve sadece ikincil bir test tekniğidir). Katı prensiplerin elde edilmesine çok yardımcı olur, ancak çok sayıda kod kokusu olan TDD'nin (patolojik) örnekleri hala mümkündür.

TDD ile sağlam ilkeler arasındaki bağlantı (yukarıdaki sonuç ile) "Test Odaklı Geliştirme Tasarımdır - TDD'nin Son Sözü" adlı bu harika hanselminute podcast'de tartışılmaktadır .