Birim testleri yalnızca 'işlevsel' yazılımı kapsamalı mı

Biz kullandığınız StructureMap yeni bir yazılım geliştirme projesinde. Ekip üyelerinden biri, temel olarak StructureMap konteyner yapılandırmasını test eden bir birim testi uyguladı . Bunu aşağıdakileri yaparak yapar;

• Uygulama ad alanımızdaki sınıflar için yapılandırılmış derleme örneği sayısını sayar.
• Sınıf düzeyinde beklenen örnekleri tanımlar
• Beklenen örneklerin toplam bulunan örneklerle eşleştiğini iddia eder.
• Beklenen örneklerin testte tanımlananlarla eşleştiğini iddia eder

Bunun bir örneği;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

Ayrıca aşağıdaki sınıf için 'birim testlerimiz' bulunmaktadır;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

Bu testlerde, IEnvironmentRepository ile alay ediyoruz, bu yüzden canlı sistemde olduğu gibi kaptan enjekte etmeyeceğiz.

Bir meslektaş, "Birim testi yalnızca kendi yapılandırmasını test eder" satırındaki bir yorumla yapı haritası yapılandırmasındaki birim testini yok saydı. Bu testin amacı açıktı ve bence tamamen geçerli. Testi yok sayan adamdan IEnvironmentRepository(test hala yok sayılırken) için yapı haritası yapılandırmasını kaldırmasını ve tam birim test paketini çalıştırmasını istedim, hepsi geçti. Daha sonra uygulamayı çalıştırdık ve kap yapılandırması artık geçersiz olduğundan uygulama sona erdi. Bence bu testin değerini kanıtladı, meslektaşım hala aynı fikirde değildi. Sadece konfigürasyonu test etmememiz gerektiğini belirtti, ancak bunun bir birim testin sorumluluğu içinde olduğunu düşünüyorum.

Yani birkaç soru;

• Geçerli bir birim testi mi - Konteynırın yapılandırmasını test ediyoruz, yapı haritası çalışmıyor (ama örtüşmeyi görebiliyorum)
• Değilse, yapılandırmayı test etmeden nasıl doğrulayabilirsiniz? Birisinin gerekli kod satırını yanlışlıkla silmesini ve teslim etmesini nasıl durdurabilirsiniz?
• Should MyClassbirim test örneğini çözmek IEnvironmentRepositorykaptan ve bu geçiş?

Bu, son derece geçerli bir otomatik testtir. Kod tabanınızın iskelet bileşenlerinin sağlamlığını doğruladıkları için onlara "mimari testler" diyorum.

IoC kapsayıcısı uygulamadaki tüm nesne ağaçlarını çözebilir ve oluşturabilir mi? Otomatik Eşleyici, kayıtlı tüm nesneleri arasında başarısızlıkla eşleşebilir mi? Soğan Mimarisindeki merkezi katman harici bir şeye referans vermiyor mu?

Bu testler, bir yapılandırma hatası içeri girdiğinde, tam suçluyu işaret ederek size çok zaman kazandırabilir. İyi çerçeveler, neyin yanlış olduğu hakkında çok kesin hata mesajları verecektir ve eğer şansınız varsa bir çalışma zamanı yığın izinin derinliklerine gömmek yerine testleri (ideal olarak, sürekli) çalıştırır etmez onları alırsınız.

Birim testleri olup olmadıkları ... muhtemelen değil, ama yine de çoğunlukla bellekte çalışıyorlar ve oldukça hızlı çalışıyorlar. Sonra tekrar bilmiyorum, evrensel olarak kabul edilen bir birim test tanımı varmış gibi değil.

Böyle bir testin problemi, programın içselliğini bir zorunluluktan ziyade test eder. Program gerektiği gibi çalışsa bile test başarısız olabilir.

Sizin durumunuzda, kap kurulumunu her değiştirdiğinizde, enjekte edilmesi gereken yeni bir bağımlılığınız olabilir, testinizi bozarsınız.

Ayrıca, ekstra bağımlılık gereksinimi eklerseniz, ancak bunu kaba eklemeyi ve konteyner testini değiştirmeyi unutursanız. her şey geçecek, ama programınız çökecek.

Daha iyi bir otomatik test, programı başlatmak ve çöküp çökmediğini görmek olacaktır.

Ünite testlerinden geçse bile entegrasyon veya UI testinde bu tür hataları yakalamanız gerekir.

Bunu söyledikten sonra, konteyner kurulumunun artan karmaşıklığı, kıçta bir acıdır. Belki de bazı 'kötü' testler buna değer.

Ünite test kodunu test eder. Bunun dışındaki her şey "diğer" otomatik testtir - buna ne istediğinizi söyleyin. Burada yapılandırmayı test ediyor gibi görünüyorsunuz. Yapılandırma ortama bağlı olarak değişebiliyorsa, birim testine ait değildir. Testin diğer testlerden farklı bir tipte olduğunu belirtmek için bir test özelliği eklemeyi düşünün.

Bağımlılık enjeksiyon kabının sorumluluğu, bir çalışma uygulamasında farklı modülleri yapıştırmaktır .

Uygulamanız için otomatik testler yazarsanız, uygulamanızın tüm boru hattını test edecek, belirli test senaryosunda yer alan tüm modüllerin birbirine yapıştırıldığı "uçtan uca testler" yürüten birkaç "entegrasyon (veya kabul) testiniz olmalıdır. doğru şekilde .

Dolayısıyla, bağımlılık enjeksiyon kabı düzgün yapılandırılmamışsa bu entegrasyon testleri başarısız olur. Bu, kapsayıcı için birim testlerini işe yaramaz hale getirir, çünkü entegrasyon testi kap yapılandırmasında olası hataları göstermelidir.

Entegrasyon testlerinde olası tüm test senaryolarını kapsamak zorunda değilsiniz, her özellik için kullanıcı arayüzünden veritabanına kadar tam bir test senaryosu.

Entegrasyon test senaryoları belirli bir bağımlılığın somutlaştırılmasını kapsamıyorsa, böyle bir tane eklemeniz yeterlidir.

Entegrasyon testleriyle, konfigürasyonları için birim testlerini yeniden yazmadan kapları özgürce değiştirebilirsiniz.

IMO, cevaplar:

1. Geçerli bir birim testi mi - Konteynırın yapılandırmasını test ediyoruz, yapı haritası çalışmıyor (ama örtüşmeyi görebiliyorum)

   • Projeniz için değil, yapı haritası için geçerli birim testi , üniter bir test, belirli bir kodu test eder ve uygulanan mantığı test etmek için gerekirse tüm bağımlılıkları alay eder. Yapılandırma mantığı bu nedenle bu kütüphane, iç StructureMap uygulanmaktadır gerekir iyi test edilmesi ve içermelidir Bahsettiğiniz bunun gibi birim testleri ve daha: böyle testlerde, çalışma zamanında dinamik olarak çeşitli yapılandırmaları alay ve görmek için test yüzlerce içermelidir konteyner gerektiği gibi davranır.

2. Değilse, yapılandırmayı test etmeden nasıl doğrulayabilirsiniz? Birisinin gerekli kod satırını yanlışlıkla silmesini ve teslim etmesini nasıl durdurabilirsiniz?

   • Yapılandırmayı ihtiyaç duyulan ortamda manuel olarak test edebilir ve ayrıca, ihtiyacınız olan belirli yapılandırmayı test eden (çalışma zamanında bir şeyler yapmanıza gerek yoktur) için bir otomasyon (otomatik test) oluşturabilirsiniz.

3. MyClass birim testi, konteynerden IEnvironmentRepository örneğini çözmeli ve bunu geçirmeli mi?

   • Hayır, bu mükemmel bir birim testtir, çünkü bağımlılığı alay eder ve MyClass mantığını izole bir şekilde test edersiniz.

UnitTest , birimin ayırmadaki istediğiniz davranışını doğrular .

Bu her türlü ifade eder konfigürasyonda olduğu değil kapsamındaki unittests .

Bununla birlikte, yapılandırmalarınız için otomatik testlere sahip olmalısınız, ancak bunlar UnitTest'ler değildir ...