Ünite testi için bağımlılık enjeksiyonu gerekli midir?

Kullanıyor bağımlılık enjeksiyon ünitesi testi için (DI) olmazsa olmaz olan?

Kod yalıtımı için başka bir alternatif düşünemiyorum, bu yüzden test edilebilir. Ayrıca, şimdiye kadar gördüğüm tüm örnekler bu modeli kullanıyor. Bunun tek geçerli seçenek olması mı yoksa başka alternatifler mi var?

DI, birim testini çok daha kolaylaştırır. Ancak yine de DI olmadan birim testleri yazabilirsiniz. DI yaygınlaşmadan önce çok sayıda birim testi yazıldı. (Tabii ki, bu kullanılan tekniklerin bazıları, bir fantezi adı olduğunu bilmeden DI ile aynı veya çok benzer.

Ben kendim de DI hakkında bilgi edinmeden önce arayüzleri ve fabrikaları çok kullandım. Gerçek fabrika sınıfı adı, bir yapılandırma dosyasından okunmuş veya SUT'a bir argüman olarak geçirilmiş olabilir.

Başka bir yaklaşım, tekilleri (veya genel olarak genel olarak erişilebilir veri) kullanmaktır. Evet, genel olarak pek çok kişi tarafından (kendim dahil) önerilmediğini biliyorum. Yine de , özellikle, eğer singleton, test senaryosuna özgü olmayan, ancak üretim ile test ortamı arasında farklılık gösteren statik konfigürasyon verileri içeriyorsa, uygulanabilir olabilir . Elbette bilinen problemleri var, yani eğer kullanabilirseniz DI üstündür. Ancak sıklıkla (örneğin eski sistemlerde) yapamazsınız.

Bunlardan bahsedersek, Eski Kodla Etkili Bir Şekilde Çalışmak , testlerin kapsadığı eski kodları almak için birçok püf noktası açıklar. Bunların çoğu hoş değildir ve uzun vadeli bir çözüm olarak değildir. Ancak, yeniden yapılanmaya başlamanıza olanak tanıyan başka bir dengesiz sistem için ilk değerli birim testlerini yaratmanıza izin veriyorlar ve sonunda (diğerleri arasında) DI'yi tanıtıyorlar.

Ünite testi için dekuplaj gereklidir. DI, ayrıştırmayı başarmanın harika bir yoludur.

Kullanmakta olduğunuz teknolojilere bağlı olarak, bağımlılıkları DI kullanmadan izole edebilirsiniz. Örneğin, .NET dünyasında, Moles bağımlılıkları DI modeli olmadan izole etmenize izin verir.

Bununla birlikte, bu izolasyon çerçevelerinin, dış bağımlılıklar (dosya sistemi, veritabanı, vb.) Kodunuzdaki durumlar için yazılmış ve amaçlanmış olduğuna inanıyorum. Bu, birinin bunu yapabileceği gerçeği, yapması gerektiği anlamına gelmez.

Bağımlılık enjeksiyonu birim testine izin verir, fakat aynı zamanda nesnenin kodunu değiştirmeden bir nesnenin davranışını değiştirmeye izin verir (açık / kapalı prensibi). Yani, sadece test edilebilir bir kod değil, aynı zamanda ortaya çıkan esnek bir koddur. Genelde, sürdürülebilir / esnek kod ile test edilebilir kod arasında ağır bir korelasyon olduğunu buldum.

Hayır, DI birim testi için şart değildir, ancak çok yardımcı olur.

Fabrikaları veya yer belirleyicileri kullanabilir ve DI ile yaptığınız gibi test edebilirsiniz (sadece bu kadar şık değil ve daha fazla kurulum gerektirir).

Ayrıca, Mock Objects , birçok çağrının bağımlılıklar yerine işlevlere atandığı eski sistemlerde önemli olacaktır. (Sahte Nesneler de uygun bir kurulumda da yaygın olarak kullanılabilir)

Testlerin neredeyse imkansız olduğu yerler olabilir. Ancak bu bağımlılık enjeksiyonunun kullanılıp kullanılmamasına dayanmamaktadır.

Hayır , birim enjeksiyon için bağımlılık enjeksiyonu şart değildir.

Bağımlılık enjeksiyonu, bazı alt işlemleri yapmak için bağımlı bir sınıf örneğine ihtiyaç duyan bir sınıfınız varsa yardımcı olur. DI yerine, bir iş yönteminin mantığını veri toplama kısmına (ünite test edilebilir olmayan) ve ünite test edilebilecek bir hesaplama kısmına ayırabilirsiniz.

Örnek (DI kullanarak) Bu uygulama Çalışan, Hesap, ...

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     if (amount > 100 && employee.isStudent())
        return false;
     if (to.getOwner().getFamiliyName() == employee.getFamilyName() && ...
        return false; // cannot transfer money to himself;
     ...
 }

Veri toplama ve hesaplama işleminden sonra:

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     return hasPermissionToTransferMoney(employee.isStudent(), employee.getFamilyName(), to.getOwner().getFamilyName(), ...);
 }

 // the actual permission calculation
 static bool hasPermissionToTransferMoney(boolean isStudent, string employeeFamilyName, string receiverFamilyName, ...)
     if (amount > 100 && isStudent)
        return false;
     if (receiverFamilyName == employeeFamiliyName && ...
        return false; // cannot transfer money to himself
     ...
 }

Hesaplama kısmı bağımlılık enjeksiyonuna gerek kalmadan kolayca test edilebilir.

• Birim testi için bağımlılık enjeksiyonu şart değildir

• Bir taraftan diğerine geçmek istediğinizde kontrolün tersine çevrilmesi esastır.

Evet, izolasyon için DI kullanımının alternatifleri vardır.

Alternatiflerden biri, gerçek nesneler yerine sahte nesneleri döndürmek için yapılan testlerden yapılandırılabilen fabrika veya ServiceLocator kullanmaktır.

Diğer bir uygun bir yalıtım çerçevesi veya alaycı bir araç kullanmaktır. Bu tür araçlar hemen hemen her modern programlama dili için var (Java, C #, Ruby ve Python için, en azından). Test edilen sınıf doğrudan bağımlılıklarını başlatsa bile, test edilen bir sınıfı diğer sınıfların / türlerin uygulanmasından izole edebilirler.