Birim testleri ile entegrasyon testleri arasındaki hattı nerede çizmeliyim? Ayrı olmalılar mı?

Üzerinde çalıştığım küçük bir MVC çerçevem ​​var. Kod tabanı kesinlikle büyük değil, ama artık sadece birkaç sınıf değil. Sonunda dalmaya ve bunun için test yazmaya başladım (evet, bunu baştan yapmalıydım biliyorum, ama API şimdiye kadar süper kararsızdı)

Her neyse, planım entegrasyon testleri de dahil olmak üzere test etmeyi son derece kolaylaştırmak. Örnek bir entegrasyon testi şu satırlar boyunca devam eder:

Sahte HTTP istek nesnesi -> MVC çerçevesi -> HTTP yanıt nesnesi -> yanıtın doğru olup olmadığını kontrol edin

Tüm bunlar herhangi bir durum veya özel araç (tarayıcı otomasyonu vb.) Olmadan gerçekleştirilebildiğinden, bunu normal birim test çerçeveleriyle kolayca yapabilirim (NUnit kullanıyorum).

Şimdi büyük soru. Birim testleri ile entegrasyon testleri arasındaki çizgiyi tam olarak nerede çizmeliyim? Birim testleri ile aynı anda yalnızca bir sınıfı (mümkün olduğunca) test etmeli miyim? Ayrıca, entegrasyon testleri birim test projemle aynı test projesine yerleştirilmeli mi?

Entegrasyon ve birim testler

Birim testlerinizi ve entegrasyon testlerinizi tamamen ayrı tutmalısınız. Birim testleriniz yalnızca bir şeyi ve bir şeyi test etmeli ve sisteminizin geri kalanının tamamen yalıtılmasını sağlamalıdır. Bir birim gevşek bir şekilde tanımlanmıştır, ancak genellikle bir yönteme veya işleve dayanır.

Her birim için testlerin yapılması mantıklıdır, böylece algoritmalarının doğru bir şekilde uygulandığını bilirsiniz ve uygulama hatalıysa hemen neyin yanlış gittiğini bilirsiniz.

Birim testi sırasında tamamen yalıtıldığınız için uygulamanızın geri kalanı gibi davranmak için saplama ve sahte nesneleri kullanırsınız. Entegrasyon testlerinin devreye girdiği yer burasıdır. Tüm birimleri ayrı ayrı test etmek harikadır, ancak birimlerin gerçekten birlikte çalışıp çalışmadığını bilmeniz gerekir.

Bu, bir modelin gerçekten bir veritabanında depolanıp depolanmadığını veya X algoritması başarısız olduktan sonra gerçekten bir uyarı verilip verilmediğini bilmek anlamına gelir.

Test odaklı geliştirme

Bir adım geri atmak ve Test Odaklı Gelişim'e (TDD) bakarak dikkate alınması gereken birkaç şey var.

1. Gerçekten geçmesini sağlayan kodu yazmadan önce birim testinizi yazarsınız.
2. Test geçişini yaparsınız, bunu gerçekleştirmek için yeterli kodu yazın.
3. Test geçtiğine göre artık geri adım atmanın zamanı geldi. Bu yeni işlevsellik sayesinde yeniden düzenleyecek bir şey var mı? Her şeyi testlerle kapsadığı için bunu güvenli bir şekilde yapabilirsiniz.

Önce entegrasyon ile son entegrasyon

Entegrasyon testleri bu TDD döngüsüne iki yoldan biriyle uyum sağlar. Onları önceden yazmayı seven insanları tanıyorum. Entegrasyon testini uçtan uca test olarak adlandırırlar ve bir uçtan uca testi, bir usecase'in tüm yolunu tamamen test eden bir test olarak tanımlarlar (bir uygulama kurmayı, önyüklemeyi, bir denetleyiciye gitmeyi, yürütmeyi, Sonucu, çıktıyı vb. kontrol etme). Daha sonra ilk ünite testleriyle başlarlar, geçerler, bir saniye eklerler, geçerlerler, vs. ... Özellik bitene kadar entegrasyon testinin yavaş yavaş gittikçe daha fazla kısmı da geçer.

Diğer stil, birim testi ile özellik birim testi oluşturmak ve daha sonra gerekli görülen entegrasyon testlerini eklemek. Bu ikisi arasındaki en büyük fark, önce entegrasyon testi durumunda, bir uygulamanın tasarımını düşünmek zorunda kalmanızdır. Bu tür, TDD'nin test etme kadar uygulama tasarımı ile ilgili olduğu fikrine katılmamaktadır.

Pratik ve uygulamaya yönelik

İşimde tüm testlerimizi aynı projede yapıyoruz. Ancak farklı gruplar var. Sürekli entegrasyon aracı, önce birim testleri olarak işaretlenenleri çalıştırır. Ancak başarılı olanlar daha yavaşsa (gerçek istekler yaptıkları için, gerçek veritabanları vb. Kullanın) entegrasyon testlerini de gerçekleştirirler.

Bu arada genellikle bir sınıf için bir test dosyası kullanıyoruz.

Önerilen Okuma

1. Testler eşliğinde büyüyen nesne yönelimli yazılım Bu kitap, entegrasyon testi ilk metodolojisinin son derece iyi bir örneğidir
2. Birim testi sanatı, dot.net'teki örneklerle Birim testi konusunda, dot.net'teki örneklerle: D Birim testi arkasındaki ilkeler hakkında çok iyi bir kitap.
3. TDD'den Robert C. Martin (Ücretsiz makaleler): Orada bağladığı ilk iki makaleyi de okuyun.

Herhangi bir test stratejisinde önemli olan Test Kapsamıdır - yani tüm işlevlerin test edildiğini gösterebilmek.

Genel olarak ve sizin durumunuzda böyle görünmeyen, aksi takdirde (örneğin DO178 Seviye A, IEC61508 SIL 4 vb.) Özel gereksinimleriniz yoksa, sınıfın veya bir modülün tüm işlevini test edebiliyorsanız (ve sistem düzeyinde testiniz varsa, o zaman sistem seviyesi testi yeterlidir. Ve benzeri aşağı. Birim testi, yalnızca testi daha fazla kapsamadığınızda gereklidir.

Birim testleri ile entegrasyon testleri arasındaki çizgiyi tam olarak nerede çizmeliyim?

Entegrasyon testi genellikle daha kolay, daha hızlı ve daha ucuz olduğundan, hattı olabildiğince uzağa çekin ...

Birim testleri ile aynı anda yalnızca bir sınıfı (mümkün olduğunca) test etmeli miyim?

Yine kapsama bağlıdır, tanımı gereği, bir birim testi tek bir birimi test etmektedir. Ancak bir modülün tamamını tek seferde tamamen test edebiliyorsanız, isterseniz bunu yapın. Aslında tek bir vuruşta birkaç birim testi gerçekleştiriyorsunuz.

Ayrıca, entegrasyon testleri birim test projemle aynı test projesine yerleştirilmeli mi?

Temel bir neden yok ... daha yüksek seviye testi bağımsız bir testçi tarafından yapılmadıkça, bu noktada sadece yürütülebilir ve minimum bir enstrüman çıkarmanız gerekir.

Küçük projelerim olduğunda tüm testleri aynı projeye sokuyorum. Daha büyük bir proje bu bölünmeye sahip olacağından, gerektiğinde onları birbirinden ayırmanın mümkün olabileceğinden emin olurum.

Birim testleri ile genellikle bir dosyada yalnızca bir sınıfı (SUT) test ederim.