Tedarikçi web hizmetlerini çağıran birim test yöntemleri


10

Bir ortak yöntem Send()ve birkaç özel yöntem ile bir sınıf var . Birkaç web servisini çağırır ve yanıtı işler. İşleme özel yöntemlerle yapılır.

Kodu test etmek istiyorum. Anladığım kadarıyla, birim testleri kodumu ayrı ayrı test etmelidir (yani tedarikçi yanıtlarını alay et).

Ayrıca özel yöntemlerin birim test edilmesi gerekmediğine inanıyorum. Ama sadece Send () yöntemini test edersem kodum tek başına test edilmiyor ve tedarikçi yanıtına bağlı.

Daha sonra sahte yöntemler ile test edebilmem için özel yöntemlerimi herkese açık hale getirmeli miyim? Kötü bir uygulama gibi görünüyor çünkü sadece sınıfın onları çağırması gerekiyor.

Özür dilerim temel bir soru, im birim testi için oldukça yeni.

C # ve VS2010 kullanıyorum


Özel bir yöntemi test etmezseniz, işe yarayıp yaramadığını nasıl anlarsınız?
Bryan Oakley

1
@BryanOakley özel bir yöntemin işe yaradığını bilmenize gerek yok, bu özel. Bunun işe yaradığını biliyorsunuz çünkü onu çağıran genel yöntemler testlerini geçiyor.
StuperUser

Ryan Oakley bağlantıya bir göz atın
Tom Squires

Merhaba Tom, bağlantıyı daha belirgin hale getirmek ve bağlantı metninin hedefini yansıtmasını sağlamak için güncelledim. Lütfen geri dönmekten çekinmeyin.
StuperUser

Yanıtlar:


18

Web hizmetleriyle ilgili kodu (yani veri gönderme ve alma) sonuçları işleyen koddan ayırmalısınız. İkinci yöntemi ayrı bir sınıfa taşıyarak gerekli yöntemleri herkese açık hale getirin. Daha sonra, dış bağımlılıklardan ayrı olarak, işleme mantığını kolayca birim test edebilirsiniz.

Böylece, kodunuzu Tek Sorumluluk İlkesi'ne de uygun hale getirmiş olursunuz . Genel bir kural olarak, özel yöntemleri test etme gereğini hissetmek, genellikle sınıfın çok fazla sorumluluğa sahip olduğunun bir göstergesidir, bu nedenle birden fazla sınıfa yeniden düzenlenmelidir.


3

Bu tür bağımlılıklara sahip bir testin ( tedarikçi web servislerini çağırma ) bir birim testten ziyade bir entegrasyon testi olduğunu düşünüyorum .


3

Diğerlerinin de belirttiği gibi, birim testlerinizin web hizmetleri veya veritabanı çağrıları gibi harici bağımlılıkları varsa, bunlar birim testleri DEĞİLDİR, entegrasyon testleridir.

Gerçek birim testleri, test etmeyi amaçladıkları bileşenin dışında dış bileşenlerden bağımsız olarak çalışabilir ve çevreye bakılmaksızın tekrarlanabilir olmalıdır. Dış web hizmetleri kapanırsa, birim testiniz başarısız olmamalıdır.

Alaycı bir çerçeve kullanarak bu sorunu çözüyoruz. Sahte nesneler, birim testimizdeki bileşenin gerçek nesneler yerine bu sahte nesneleri kullanması için bir bileşen sahte oluşturmamızı sağlar. Sahte nesneleri test edilebilir bileşene enjekte edebilir ve hangi argüman (lar) ı beklediğimizi, çağrıldığında neyin geri dönmesini istediğimizi, hangi istisnaları atmamızı istediğimizi belirtebiliriz. Ünite testlerinizin güvenilirliğini ve bağımsızlığını artıracağından konu hakkında daha fazla bilgi almanızı şiddetle tavsiye ederim.

Farklı C # alaycı çerçevelerde iyi bir yazı için aşağıdaki SO iş parçacığına bakın:

/programming/37359/what-c-mocking-framework-to-use

EDIT: Açıkça hassas için, ben test sonunda veritabanı değişiklikleri geri alabilirsiniz DbUnit veya diğer işlem araçları bahsetmeyi ihmal etti. Bunlar da tekrarlanabilir ve üretilen test verileri ile ortam agnostik olabilir, bu nedenle bu durumda bir Mocking Framework gerekmez.


Birisi düşüşü açıklayabilir mi? PHP, ROR, NoSQL veritabanları, sunucudaki Javascript, Apple ürünleri veya başka bir fab trendini kopyalamamıştım, yine de STILL bir drive-by downvote aldım: S
maple_shaft

Sanırım birisi kendi birim testleri "hiç birim testleri değil" denilen (ben değildi) :) gibi değildi
Daniel B
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.