Test Odaklı Geliştirme (TDD) bir tasarım değildir. Tasarımınızı etkileyen bir gerekliliktir. Tıpkı iş parçacığı için güvenli olmanız gerekiyormuş gibi, bu bir tasarım değil. Yine, tasarımınızı etkileyen bir gerekliliktir.
Diğer tüm tasarım kaygılarını neşeyle görmezden gelir ve dini olarak TDD kurallarına uyursanız, kodunuz bok haline geldiğinde TDD'yi suçlamayın. Test edilebilir bok olacak ama bok olacak.
Test edilebilir saçmalık hakkında güzel bir şey, yeniden canlandırılabilir saçmalık olması, bu yüzden bazı insanlar için yeterince iyi. Sadece gerektiğinde fantezi olacağız. Diğerleri bundan nefret eder ve bunun için TDD'yi suçlar. Hayýr. Bu senin iţin.
Etki Alanına Dayalı Tasarım (DDD) , TDD'nin kırmızı yeşil refactor döngüsünden önce yaptığınız bir şeydir.
DDD, kodda, sistemin ayrıntılarından büyük ölçüde habersiz olan bir alan uzmanının, sistemin nasıl kontrol edileceğini anlayabileceği bir alan oluşturma ve koruma çabasıdır. Bu soyutlama ve sorunlu bir alanı tanıdık bir şekilde modelleyerek yapılır.
DDD sistemi aşağıdaki gibi bir mimariye sahip olabilir:
Bu DDD mimarisi birçok isimle geçer: Temiz , Soğan , Altıgen , vb.
İşte birçok kişi bu tasarıma baktıklarında gördüğüm bağlantıyı kesme. Bu somut değil. Bu tasarımı takip edebilirim ve burada diyagramda gördüğünüz hiçbir şeyi yazmadım. Başkalarının bir kullanım örneği nesnesi veya bir varlık sınıfı olması gerektiğinde ısrar ettiğini görüyorum. Bunların ne olduğu, kiminle ve nasıl konuşabileceğinizi anlatan bir dizi kuraldır.
Bu kadar. Bu tasarımın kurallarına uyun ve küçük kalbinizi TDD yapabilirsiniz. TDD kiminle konuştuğun umurunda değil. Bir şeyi yapan her şeyin bir düğmeye tıklandığında işe yarayıp yaramayacağı kanıtlanabilir. Hayır, bir yerlerde bir şey bozuldu. Tam olarak neyin kırıldığını söyler.
Hala belirsiz mi? Bak Controler- Use Case Interactor- Presentersağ alt köşesinde diyagram. İşte birbirleriyle iletişim kuran üç somut şey. Elbette bu DDD ama buraya TDD'yi nasıl eklersiniz? Sadece beton şeylerle alay et. Sunum yapan kişi bilgi almalıdır. Bir PresenterMocksınıf, elde etmeyi beklediğiniz şeyi aldığını kontrol etmenin iyi bir yolu olacaktır. Ver ve sür sen sanki ve birim testi için güzel bir yol var o bunu almak için beklenen var ise sahte söyleyecektir çünkü.Use Case InteractorPresenterMockUse Case InteractorControllerUse Case Interactor
Şuna bir bak. TDD memnun kaldı ve DDD tasarımımızla futz yapmak zorunda kalmadık. Bu nasıl oldu? İyi bir şekilde ayrılmış bir tasarımla başladık.
TDD'yi tasarımı yönlendirmek için kullanırsanız (sadece D geliştirmesini değil ), içine koyduğunuz çabayı yansıtan bir tasarım elde edersiniz. Eğer istediğin buysa. Ancak TDD'nin amacı bu değildi. Bunun eksik olduğu şey TDD'nin hatası değildir.
TDD tasarımla ilgili değil. TDD'yi kullanmak için tasarım değişiklikleri yapmanız gerekiyorsa, test etmekten daha büyük sorunlarınız var.