Entegrasyon ve birim testleri arasındaki fark nedir?


307

Birim testleri ve entegrasyon testlerinin ders kitabı tanımını biliyorum. Merak ettiğim şey, birim testleri yazmanın zamanı geldiğinde ... Mümkün olduğunca çok sayıda sınıfı kapsayacak şekilde yazacağım.

Örneğin, bir Wordsınıfım varsa , Wordsınıf için bazı birim testleri yazacağım . Sonra, benim yazmaya başlamak Sentencesınıfını ve bu etkileşim gerektiğinde Wordsınıf, sık sık benim birim ikisi de test etmenizi böyle testler yazacak Sentenceve Wordnerede etkileşim en azından yerlerde ....

Bu testler esasen entegrasyon testleri haline geldi mi, çünkü şimdi bu 2 sınıfın entegrasyonunu test ediyorlar mı, yoksa sadece 2 sınıfa yayılan bir birim testi mi?

Genel olarak, bu belirsiz çizgi nedeniyle, nadiren aslında entegrasyon testleri yazacağım ... veya bitmiş ürünü kullanıyorum, manuel ve nadiren kapsamın ötesinde olsa da, tüm parçaların gerçek entegrasyon testlerini düzgün çalışıp çalışmadığını görmek için kullanıyorum her bir özelliğin?

Entegrasyon testlerini yanlış anlıyor muyum yoksa entegrasyon ve birim testleri arasında gerçekten çok az fark var mı?

Yanıtlar:


300

Benim için temel fark, entegrasyon testlerinin bir özelliğin çalışıp çalışmadığını veya bozulduğunu ortaya çıkarmasıdır, çünkü kodu gerçeğe yakın bir senaryoda vurgulamaktadırlar. Bir veya daha fazla yazılım yöntemini veya özelliğini çağırır ve beklendiği gibi davranıp davranmadıklarını test ederler.

Diğer taraftan, tek bir yöntemi test eden bir Birim testi , yazılımın geri kalanının doğru çalıştığı varsayımına (genellikle yanlış) dayanır, çünkü her bağımlılığı açıkça atar.

Bazı özelliği uygulamadan bir yöntem için bir birim test yeşil olduğunda Dolayısıyla, bu yok değil özellik çalışıyor demek.

Diyelim ki böyle bir yerde bir yöntem var:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  Log.TrackTheFactYouDidYourJob();
  return someResults;
}

DoSomethingmüşteriniz için çok önemlidir: önemli olan tek özellik budur. Bu nedenle genellikle iddia eden bir Salatalık belirtimi yazıyorsunuz: özelliğin çalışıp çalışmadığını doğrulamak ve iletmek istiyorsunuz .

Feature: To be able to do something
  In order to do something
  As someone
  I want the system to do this thing

Scenario: A sample one
  Given this situation
  When I do something
  Then what I get is what I was expecting for

Şüphesiz: Test geçerse, çalışan bir özellik sunduğunuzu iddia edebilirsiniz. İşletme Değeri diyebilirsiniz .

Bir birim testi yazmak istiyorsanız DoSomething, sınıfların ve yöntemlerin geri kalanının çalıştığını (yani, yöntemin kullandığı tüm bağımlılıkların doğru çalıştığını) iddia etmeli (bazı alayları kullanarak) ve yönteminizin çalıştığını iddia etmelisiniz.

Pratikte şöyle bir şey yaparsınız:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
  return someResults;
}

Bunu Bağımlılık Enjeksiyonu veya bazı Fabrika Yöntemleri veya herhangi bir Mock Çerçevesi ile veya test edilen sınıfı genişleterek yapabilirsiniz.

Diyelim ki bir hata var Log.DoSomething(). Neyse ki, Gherkin spec onu bulacak ve uçtan uca testleriniz başarısız olacak.

Özellik çalışmaz, çünkü Logbozulur, [Do your job with someInput]işini yapmaması nedeniyle değildir. Ve bu arada, [Do your job with someInput]bu yöntemin yegane sorumluluğu var.

Ayrıca, Log100 diğer özellikte, 100 diğer sınıfın 100 diğer yönteminde kullanıldığını varsayalım .

Evet, 100 özellik başarısız olacak. Ancak, neyse ki, 100 uçtan uca testler de başarısız oluyor ve sorunu ortaya koyuyor. Ve evet: gerçeği söylüyorlar .

Çok faydalı bilgiler: Kırık bir ürünüm olduğunu biliyorum. Aynı zamanda çok kafa karıştırıcı bir bilgi: bana sorunun nerede olduğu hakkında hiçbir şey söylemiyor. Bana semptomu iletiyor, kök nedeni değil.

Yine de, DoSomethingbirim testi yeşil, çünkü Logasla kırılmayacak şekilde yapılmış sahte kullanıyor . Ve evet: açıkça yalan söylüyor . Bu iletişim bozuk bir özelliği çalışıyor. Nasıl faydalı olabilir?

( DoSomething()Birim testi başarısız olursa, şunlardan emin olun: [Do your job with someInput]bazı hatalar var.)

Bunun bozuk bir sınıfa sahip bir sistem olduğunu varsayalım: Sınıfı bozuk bir sistem

Tek bir hata birkaç özelliği kıracak ve birkaç entegrasyon testi başarısız olacaktır.

Tek bir hata birkaç özelliği kıracak ve birkaç entegrasyon testi başarısız olacak

Öte yandan, aynı hata sadece bir birim testi kıracaktır.

Aynı hata sadece bir birim testi kıracak

Şimdi, iki senaryoyu karşılaştırın.

Aynı hata sadece bir birim testi kıracaktır.

  • Kırık kullanan tüm özellikleriniz Logkırmızı
  • Tüm birim testleriniz yeşil, sadece için birim testi Logkırmızı

Aslında, kırık bir özellik kullanan tüm modüller için birim testleri yeşildir, çünkü alay kullanarak bağımlılıkları ortadan kaldırmışlardır. Başka bir deyişle, ideal, tamamen kurgusal bir dünyada koşarlar. Ve böcekleri izole etmenin ve onları aramanın tek yolu budur. Birim testi alay etme anlamına gelir. Alaycı değilseniz, birim testi yapmazsınız.

Fark

Entegrasyon testleri neyin çalışmadığını gösterir. Ancak sorunun nerede olabileceğini tahmin etmede hiçbir faydaları yoktur .

Birim testleri , hatanın tam olarak nerede olduğunu gösteren tek testlerdir . Bu bilgileri çizmek için, yöntemi diğer tüm bağımlılıkların doğru çalışması gereken sahte bir ortamda çalıştırmaları gerekir.

Bu yüzden cümlenizin "Yoksa sadece 2 sınıfa yayılan bir birim sınav mı?" İfadesinin bir şekilde yerinden edildiğini düşünüyorum. Birim testi asla 2 sınıfa yayılmamalıdır.

Bu cevap temelde burada yazdıklarımın bir özeti: Birim testleri yalan söylüyor, bu yüzden onları seviyorum .


6
Gerçekten iyi bir cevap! Ancak ben sadece alay sadece birim test için olmadığını eklemek istiyorum. Pek çok entegrasyon testi vakasında da çok yararlı olabilir.
n.Stenvang

1
Mükemmel cevap! Sadece iki noktaya katılmıyorum: 1) entegrasyon testlerinin "sorunun nerede olabileceğini tahmin etmede bir faydası olmadığını"; ve 2) "bir birim test asla 2 sınıfa yayılmamalıdır". Çok sayıda entegrasyon testi oluşturdum ve kırıldıklarında, tam bir yığın izlemesi veya tek bir başarısız iddiası (bu durumda kaynağı bulmak daha zor olabilir), ancak sorunun kaynağını belirlemek genellikle zor değildir, ancak entegrasyon testi hata ayıklama için içerilen bir bağlam sağladığı için çok fazla değil). (devam ediyor)
Rogério

5
Ünite testleri , kendi ayrı ünite testlerine sahip olması gereken ortak sınıflar olmadıkça, birden fazla sınıf uygulayabilir. Bir örnek, kamu tarafından test edilmiş bir sınıfın yalnızca kamu sınıfını desteklemek için var olan kamuya açık olmayan diğer yardımcı sınıfları kullanmasıdır; bu durumda, "birim" iki veya daha fazla sınıf içerir. Diğer bir durum, çoğu sınıfın alay konusu veya izole edilmesi anlamsız üçüncü taraf sınıfları (String / string sınıfı, toplama sınıfları vb.) Kullanmasıdır; bunları sadece test kapsamının dışında kalan kararlı ve güvenilir bağımlılıklar olarak görüyoruz.
Rogério

2
Entegrasyon testleri ile kök problemini bulmak biraz daha zor, ancak yine de hata ayıklama ve kök problemini bulma. Birim testlerinin sık sık başarısız olduğunu varsayarsak, yalnızca entegrasyon testleriniz varsa hataları düzeltmek için nadiren biraz daha zaman alacaktır, ancak daha sonra test bileşenlerinin entegrasyonunun katma değerini de alırsınız ve yazma zamanından tasarruf edersiniz birim testleri. Sanırım bu iddia (patronumdan geldi) yanlış, ama onu nasıl ikna edebileceğimden emin değilim, herhangi bir fikir?
BornToCode

1
Bu cevabın gerekçesiyle, birim testleri yazmayı atlamanın ve başarısız olduklarında bütünleşme testlerinin kaynağını bularak tasarruf edilen zamanın harcanmasının daha etkili olabileceği iddia edilebilir.

62

Birim testleri yazdığımda, test edilmekte olan kodun kapsamını şu anda yazdıkları bağımlılıklarla yazdığım sınıfa sınırlandırıyorum. Eğer bir Cümle sınıfı yazıyorum ve Cümlenin Word'e bağımlılığı varsa, sahte bir Word kullanacağım. Word ile alay ederek sadece arayüzüne odaklanabilir ve Cümle sınıfımın çeşitli arayüzlerini Word arayüzüyle etkileşime girerken test edebilirim. Bu şekilde yalnızca Cümlenin davranışını ve uygulamasını test ediyorum ve aynı zamanda Word'ün uygulanmasını test ediyorum.

Cümlenin Word'ün arayüzüne dayalı olarak Word ile etkileşime girdiğinde Cümlenin doğru davranmasını sağlamak için birim testleri yazdıktan sonra, etkileşimler hakkındaki varsayımlarımın doğru olduğundan emin olmak için entegrasyon testini yazıyorum. Bunun için gerçek nesneleri tedarik ediyorum ve hem Cümle hem de Word kullanarak sonuçlanacak bir özellik kullanan bir test yazıyorum.


43

10 bitim: D

Bana her zaman Birim Testlerin tek bir bileşenin testi olduğu söylendi - ki bu da sonuna kadar kullanılmalıdır. Çoğu bileşen daha küçük parçalardan yapıldığından, şimdi bu birçok seviyeye sahip olma eğilimindedir. Benim için bir birim sistemin işlevsel bir parçasıdır. Bu yüzden değerli bir şey sağlamalıdır (yani, dize ayrıştırma yöntemi değil, belki de bir HtmlSanitizer ).

Entegrasyon Testleri bir sonraki adımdır, bir veya daha fazla bileşen alır ve gerektiği gibi birlikte çalıştıklarından emin olur .. O zaman bileşenlerin ayrı ayrı nasıl çalıştığı konusunda endişelerin karmaşıklığının üzerindesiniz , ancak HtmlEditControl'ünüze html girdiğinizde , bir şekilde sihirli bir şekilde geçerli olup olmadığını bilir ..

Onun gerçek bir hareketli çizgi olsa .. Ben daha çok tam durağı çalışmak için lanet kod almak odaklanmak istiyorum ^ _ ^


23

Birim testleri taklit kullanır

Bahsettiğiniz şey, sisteminizin tüm entegrasyonunu gerçekten test eden entegrasyon testleridir. Ancak birim testi yaptığınızda her bir birimi ayrı ayrı test etmeniz gerekir. Diğer her şey alay edilmeli. Yani Sentencesınıf durumunuzda , eğer Wordsınıf kullanıyorsa , Wordsınıfınız alay konusu olmalıdır. Bu şekilde, yalnızca Sentencesınıf işlevselliğinizi test edersiniz .


Bunun eski bir gönderi olduğunu biliyorum ama yeni rastladım. Cümle sınıfının etkileşime girdiği Font adında üçüncü bir sınıfınız varsa ve Word ve Cümle sınıfı arasındaki işlevselliği test etmek istiyorsanız, o zaman Font sınıfıyla alay etmek zorunda kaldınız, ancak bu bir birim testi yapmaz. Demek istediğim, alayları kullanmanın mutlaka bir ünite testi yapmaması, alaylar da entegrasyon testlerinde kullanılabilir.
n.Stenvang

2
Tabii ki alaylar entegrasyon testlerinde kullanılabilir, ancak bir birim testinin gerçekte böyle olması, birimin dışındaki her şeyin simüle edilmesi gerekir . Entegrasyon testleri sahte kullanıyorsa, muhtemelen kısmi entegrasyon testleridir (bu tür bir terim varsa). Elbette yukarıdan aşağıya veya aşağıdan yukarıya olan kısmi entegrasyon testleri vardır. İkincisi genellikle eskiden alay gerektirmez.
Robert Koritnik

17

Bence entegrasyon testlerini düşünmeye başladığınızda, mantıksal katmanlar yerine fiziksel katmanlar arasında bir çarpı işareti söylüyorsunuz.

Örneğin, testleriniz içerik üretmekle ilgiliyse, bu bir birim testtir: testiniz sadece diske yazmakla ilgileniyorsa, yine de bir birim testtir, ancak hem G / Ç hem de dosyanın içeriğini test ettiğinizde, o zaman kendinize bir entegrasyon testi yaptırırsınız. Bir hizmet içindeki bir işlevin çıktısını test ettiğinizde, bu bir birim sınamasıdır, ancak bir servis çağrısı yaptığınızda ve işlev sonucunun aynı olup olmadığını gördüğünüzde, bu bir entegrasyon testidir.

Teknik olarak, zaten tek bir sınıfı test edemezsiniz. Sınıfınız diğer birkaç sınıftan oluşuyorsa ne olur? Bu otomatik olarak bir entegrasyon testi yapar mı? Ben öyle düşünmüyorum.


8
"Teknik olarak yine de sadece bir sınıfı test edemezsiniz. Ya sınıfınız birkaç sınıftan oluşuyorsa?" Eh, "katı" bir birim test sadece tüm bağımlılıkları alay / saplama olurdu. Ancak, bu her zaman pratik olup olmadığı tartışmalıdır ...
sleske

2
Bu gerçek sieske - önemli olan bağımlılıkları mutlak bir minimumda tutabilmek.
Jon Limjap

-1, birim testi tek bir özelliği değil, tek bir yazılım işlevini veya sınıfı test eder, yani mantıksal bir yazılım birimini test eder.
CharlesB

12

Tek sorumluluk tasarımını kullanarak, siyah ve beyaz. 1'den fazla sorumluluk, bir entegrasyon testi.

Ördek testi ile (görünüyor, quacks, waddles, onun bir ördek), sadece 1'den fazla yeni nesne ile bir birim testi.

Mvc'ye girip test ettiğinizde, denetleyici testleri her zaman entegrasyon halindedir, çünkü denetleyici hem model birimi hem de görünüm birimi içerir. Bu modelde test mantığı, bir birim testi derdim.


10

Testlerinizin doğası

Bir birim test modülü X bir test olduğu beklediği (ve kontrol eder) tek modül X sorunlar

Bir entegrasyon testi birçok modül işbirliği kaynaklanan beklediği sorunlar olduğu bir testtir arasındaki modüllerin böylece bu sorunların tek başına birim testleri kullanılarak bulmak zor olacağını.

Testlerinizin doğasını aşağıdaki terimlerle düşünün:

  • Risk azaltma : Testler bunun içindir. Sadece birim testler ve entegrasyon testlerinin bir kombinasyonu size tam risk azaltımı sağlayabilir, çünkü bir yandan birim testleri, modüller arasındaki uygun etkileşimi doğal olarak test edemezken, diğer yandan entegrasyon testleri sadece önemsiz bir modülün işlevselliğini kullanabilir küçük bir dereceye kadar.
  • Test yazma çabası : Entegrasyon testleri çabadan tasarruf edebilir, çünkü daha sonra taslaklar / sahte / alaylar yazmanız gerekmeyebilir. Ancak birim testleri, bu saplamalar / sahte / alayları uygularken (ve korurken!) Çabadan da tasarruf edebilir, test kurulumunu onlarsız yapılandırmaktan daha kolay olur.
  • Test yürütme gecikmesi : Ağır işlemler (DB'ler veya uzak sunucular gibi harici sistemlere erişim gibi) içeren entegrasyon testleri yavaş olma eğilimindedir. Bu, birim testlerinin çok daha sık yapılabileceği anlamına gelir, bu da bir şey başarısız olursa hata ayıklama çabasını azaltır, çünkü bu arada neyi değiştirdiğiniz hakkında daha iyi bir fikriniz vardır. Test odaklı geliştirme (TDD) kullanıyorsanız bu özellikle önem kazanır.
  • Çaba ayıklama : bir entegrasyon testi başarısız olursa karışanlar çok kod olduğundan, ancak birim testlerin hiçbiri, bu, çok sakıncalı olabilir gelmez olabilir sorunu içermektedir. Bu daha önce sadece birkaç satır değişip değişmediğini büyük bir sorun değil - ama entegrasyon testleri yavaş çalışmasına gibi, sen belki vermedi değil bu kadar kısa aralıklarla bunları çalıştırmak ...

Bir entegrasyon testinin bağımlılıklarının bir kısmını hala saplayabileceğini / sahte / alay edebileceğini unutmayın . Bu, birim testleri ve sistem testleri (en kapsamlı entegrasyon testleri, tüm sistemi test etme) arasında bol miktarda orta yol sağlar.

Her ikisini de kullanma pratiği

Bu yüzden pragmatik bir yaklaşım şöyle olacaktır: Entegrasyon testlerine makul derecede olabildiğince esnek bir şekilde güvenin ve bunun çok riskli veya uygunsuz olacağı birim testleri kullanın. Bu düşünme tarzı, birim testlerin ve entegrasyon testlerinin bazı dogmatik ayrımcılığından daha yararlı olabilir.


10

Birim testinde izole edilen her parçayı test edersiniz: resim açıklamasını buraya girin

entegrasyon testinde sisteminizin birçok modülünü test edersiniz:

resim açıklamasını buraya girin

ve sadece birim testleri kullandığınızda olan budur (genellikle her iki pencere de çalışır, maalesef birlikte değil):

resim açıklamasını buraya girin

Kaynaklar: kaynak1 kaynak2


Üç resminiz var, sadece iki kaynağınız var.
gerrit

1
@gerrit ilk kaynağa bir göz atın - iki resim oradan
Michu93

1
Bu yanıtı seviyorum D
Dzenis H.

8

Bence cevap "Neden önemli?"

Birim testleri yaptığınız bir şey ve entegrasyon testleri yapmadığınız bir şey mi? Ya da tam tersi? Tabii ki hayır, ikisini de yapmaya çalışmalısınız.

Birim testlerinin Hızlı, İzole, Tekrarlanabilir, Kendini Doğrulayan ve Zamanında olması gerektiğinden ve entegrasyon testlerinin yapılmaması gerektiği için mi? Tabii ki hayır, tüm testler bu olmalıdır.

Çünkü birim testlerde alayları kullanıyorsunuz ama entegrasyon testlerinde kullanmıyorsunuz? Tabii ki değil. Bu, yararlı bir entegrasyon testine sahip olduğum takdirde, bir kısım için alay eklememe izin verilmiyorsa, testimi "birim test" olarak yeniden adlandırmam veya üzerinde çalışmak için başka bir programcıya teslim etmemden korkacağım anlamına gelir.

Birim testleri bir birimi test ettiğinden ve entegrasyon testleri birkaç birimi test ettiğinden mi? Tabii ki değil. Bunun pratik önemi nedir? Testlerin kapsamı hakkındaki teorik tartışma, uygulamada zaten parçalanmaktadır, çünkü "birim" terimi tamamen bağlama bağlıdır. Sınıf düzeyinde, bir birim bir yöntem olabilir. Birleştirme düzeyinde, bir birim bir sınıf olabilir ve hizmet düzeyinde bir birim bir bileşen olabilir. Ve sınıflar bile başka sınıflar kullanır, yani birim hangisidir?

Önemi yok.

Test önemlidir, İLK önemlidir, tanımlarla ilgili kılları bölmek sadece yeni gelenleri teste karıştıran bir zaman kaybıdır.


5
-1 Tanım, insanları her zaman ne anlama geldiklerini açıklamadan aynı terimleri kullanmalarını sağlayan şeydir ve işbirliği için gereklidir. Bu nedenle, her iki kavram arasındaki farkı anlamak esastır.
CharlesB

@CharlesB'in belirttiği gibi, her seferinde açıklamaya veya herkesin karışıklığa neden olan farklı bir tanım bulmasına gerek yoktur. Testler farklı yazılacak ve farklı şekilde çalışacaktır, ancak bu, her ikisinin de farklılıkları tanımlamak isteyerek yapılmaması gerektiği anlamına gelmez.
Shane

Yanıtın sonucu aşırı olabilir, ancak puanlarının çoğu oldukça geçerlidir: Birim testleri ve entegrasyon testleri , ayrıntı düzeyi dışında çoğunlukla aynı şeydir ve aralarında nerede bir çizgi çizilmesi gerektiği açık değildir.
Lutz Prechelt

Bu, profesyonel bir ortamda ortak bir dil oluştururken yardımcı olmaz. Çoğunlukla haklı olmanıza rağmen, ortak bir dile sahip olmamanın ekip arasında yanlış anlaşılmalar ve karışıklık yaratacağı önemli değil. Bence en iyi seçenek, ekibin terimleri ve tanımları üzerinde anlaşmasıdır.
user924272

4

Sınıf1 için birim testlerinin class1 özelliklerini test etmesi ve class2 için birim testlerinin özelliklerini test etmesi ve veritabanına isabet etmemesi şartıyla hala birkaç etkileşimli sınıfı bir birim testi olarak adlandıracağımı düşünüyorum.

Yığımın çoğundan geçtiğinde ve hatta veritabanına çarptığında bir sınama entegrasyon sınaması diyorum.

Bu soruyu gerçekten seviyorum, çünkü TDD tartışması bazen bana biraz daha saf geliyor ve bazı somut örnekler görmek benim için iyi.


4

Ben de aynı - Ben tüm birim testleri diyorum, ama bir noktada ben sık sık "..IntegrationTest" olarak adlandırılan çok fazla kapsayan bir "birim testi" var - sadece bir isim değişikliği, başka bir şey değişmez.

Ben "atom testleri" (bir küçük sınıf veya bir yöntem test) birim testleri (sınıf seviyesi) ve entegrasyon testleri - ve sonra fonksiyonel test (normalde yukarıdan aşağı çok daha fazla şey kapsayan) bir devam olduğunu düşünüyorum - temiz bir kesim yok gibi görünüyor.

Testiniz veri kurar ve belki bir veritabanı / dosya vb. Yüklerse, belki de daha fazla bir entegrasyon testi (daha az alay ve daha gerçek sınıflar kullandığım entegrasyon testleri buluyorum, ancak bu, bazılarını alay edemeyeceğiniz anlamına gelmez. sistemin).


4

Birim Sınaması , kaynak kodu ayrı birimlerinin düzgün çalıştığını doğrulayan bir test yöntemidir.

Entegrasyon Testi , ayrı yazılım modüllerinin grup halinde birleştirildiği ve test edildiği yazılım test aşamasıdır.

Wikipedia , birimi Java / C # 'da bir yöntem olan bir uygulamanın en küçük test edilebilir parçası olarak tanımlar. Ancak, Word ve Cümle sınıfı örneğinizde, muhtemelen cümle için testleri yazacağım çünkü cümle sınıfını test etmek için sahte bir kelime sınıfı kullanmak aşırıya kaçabilirdi . Yani cümle benim birimim ve kelime o birimin uygulama detayıdır.


4

Entegrasyon testleri: Veritabanı kalıcılığı test edilir.
Birim testleri: Veritabanı erişimi alay edildi. Kod yöntemleri test edilir.


3

Birim testi, bir iş birimine veya isterseniz bir kod bloğuna karşı test ediyor. Genellikle tek bir geliştirici tarafından gerçekleştirilir.

Entegrasyon testi, bir geliştirici kodlarını bir kaynak kontrol havuzuna verdiğinde, tercihen bir entegrasyon sunucusunda gerçekleştirilen testi ifade eder. Entegrasyon testi, Cruise Control gibi yardımcı programlar tarafından gerçekleştirilebilir.

Böylece, yaptığınız iş biriminin çalıştığını doğrulamak için birim testinizi yaparsınız ve ardından tümleştirme testi, depoya eklediğiniz her şeyin başka bir şey kırmadığını doğrular.


2

Üniteyi beyaz kutu bir sınıfı test eden testleri deniyorum. Sınıfın gerektirdiği bağımlılıklar sahte olanlarla değiştirilir.

Entegrasyon testleri, birden fazla sınıfın ve etkileşimlerinin aynı anda test edildiği testlerdir. Sadece bu durumlarda bazı bağımlılıklar sahte / alay konusu.

Bağımlılıklarından biri gerçek değilse (yani sahte değil), örneğin IFormsAuthentication), Controller'ın entegrasyon testlerini çağırmazdım.

İki test türünün ayrılması, sistemi farklı düzeylerde test etmek için yararlıdır. Ayrıca, entegrasyon testleri uzun ömürlü olma eğilimindedir ve birim testlerin hızlı olması beklenir. Yürütme hızı ayrımı, farklı şekilde yürütüldüğü anlamına gelir. Geliştirme süreçlerimizde, birim testleri check-in sırasında (süper hızlı oldukları için iyidir) ve entegrasyon testleri günde bir / iki kez yapılır. Entegrasyon testlerini olabildiğince sık çalıştırmaya çalışıyorum, ancak genellikle veritabanına isabet / dosyalara yazma / rpc / vb.

Bu da bir başka önemli noktayı ortaya çıkarır, birim testleri IO'ya (örneğin disk, ağ, db) çarpmaktan kaçınmalıdır. Aksi takdirde çok yavaşlarlar. Bu IO bağımlılıklarını tasarlamak biraz çaba gerektiriyor - "birim testleri hızlı olmalı" kuralına sadık olduğumu itiraf edemem, ancak eğer öyleyse, çok daha büyük bir sistemin faydaları çok çabuk belirginleşir .


2

Analojilerle Basit Açıklama

Yukarıdaki örnekler çok işe yarıyor ve bunları tekrarlamam gerekmiyor. Bu yüzden anlamanıza yardımcı olacak örnekler kullanmaya odaklanacağım.

Entegrasyon Testleri

Entegrasyon testleri her şeyin birlikte çalışıp çalışmadığını kontrol eder. Bir saatte birlikte çalışan bir dizi çarkı düşünün. Bir entegrasyon testi şu olurdu: saat doğru zamanı mı söylüyor? Hala 3 gün içinde doğru zamanı mı söylüyor?

Size söylenen tek şey, genel parçanın çalışıp çalışmadığıdır. Başarısız olursa: size tam olarak nerede başarısız olduğunu söylemez.

Birim Testleri

Bunlar gerçekten özel test türleridir. Size belirli bir şeyin işe yarayıp yaramadığını söylerler. Bu tür testlerin anahtarı, diğer her şeyin iyi çalıştığını varsayarken sadece belirli bir şeyi test etmesidir. Kilit nokta bu.

Örnek: Bu noktayı bir örnek kullanarak inceleyelim:

  • Örnek olarak bir araba alalım.
  • Bir araba için entegrasyon testi: örneğin araba Woop Woop'a geri dönüyor mu? Bunu yaparsa, bir otomobilin genel bir bakış açısından çalıştığını güvenle söyleyebilirsiniz. Bu bir entegrasyon testidir. Başarısız olursa, aslında nerede başarısız olduğu hakkında hiçbir fikriniz yok: radyatör, şanzıman, motor veya karbüratör mü? Hiçbir fikrin yok. Herhangi bir şey olabilir.
  • Araba için birim testi : Motor çalışıyor mu? Bu testler, arabadaki diğer her şeyin iyi çalıştığını varsayar. Bu şekilde, bu belirli birim testi başarısız olursa: sorunun motorda yattığından emin olabilirsiniz - böylece sorunu hızlı bir şekilde izole edebilir ve düzeltebilirsiniz.

Saplamaları Kullanma

  • Otomobil entegrasyon testinizin başarısız olduğunu varsayalım. Echuca'ya başarıyla gitmiyor. Sorun nerede?

  • Şimdi motorunuzun özel bir yakıt enjeksiyon sistemi kullandığını ve bu motor ünitesi testinin de başarısız olduğunu varsayalım. Başka bir deyişle, hem entegrasyon testi hem de motor ünitesi testi başarısız oldu. O zaman sorun nerede? (Cevabı almak için kendinize 10 saniye verin.)

  • Sorun motorda mı yoksa yakıt enjeksiyon sisteminde mi?

Sorunu burada görüyor musun? Tam olarak neyin başarısız olduğunu bilmiyorsunuz. Farklı harici bağımlılıklar kullanırsanız, bu 10 taneden her biri soruna neden olmuş olabilir - ve nereden başlayacağınızı bilemezsiniz. Bu yüzden birim testler, diğer her şeyin iyi çalıştığını varsaymak için taslakları kullanır.


1

Bu soru biraz akademik, değil mi? ;-) Benim açımdan: Benim için bir entegrasyon testi, on parçanın iki parçası birlikte gidiyorsa değil, tüm parçanın testidir. Entegrasyon testimiz, ana yapının (40 proje içeren) başarılı olup olmayacağını gösterir. Projeler için tonlarca birim testimiz var. Benim için birim testleri ile ilgili en önemli şey, bir birim testinin başka bir birim testine bağlı olmaması gerektiğidir. Yani benim için yukarıda açıkladığınız her iki test de bağımsız ise birim testlerdir. Entegrasyon testleri için bunun önemli olması gerekmez.


1

Bu testler esasen entegrasyon testleri haline geldi mi, çünkü şimdi bu 2 sınıfın entegrasyonunu test ediyorlar mı? Yoksa sadece 2 sınıfa yayılan bir birim sınav mı?

Bence Evet ve Evet. 2 sınıfa yayılan birim testiniz bir entegrasyon testi oldu.

Sistemin bu bölümleri farklı geliştiriciler tarafından uygulanacak kadar büyük olduğunda önemli olan MockWord sınıfı olan Cümle sınıfını MockWord sınıfıyla test ederek bundan kaçınabilirsiniz. Bu durumda, Word tek başına birim test edilir, Cümle MockWord yardımıyla birim test edilir ve sonra Cümle Word ile entegrasyon testinden geçirilir.

Exaple gerçek fark aşağıdaki olabilir 1) 1.000.000 eleman dizisi kolayca birim test ve iyi çalışıyor. 2) BubbleSort kolayca 10 elemanlı sahte dizi üzerinde birim test ve iyi çalışır 3) Entegrasyon testi bir şey çok iyi olmadığını gösterir.

Bu parçalar tek kişi tarafından geliştirilirse, büyük olasılıkla sorun, BubbleSoft'u birim test ederken geliştiricinin zaten gerçek diziye sahip olması ve sahte uygulamaya ihtiyaç duymaması nedeniyle bulunur.


1

Ayrıca, hem birim testlerinin hem de entegrasyon testlerinin, örneğin JUnit kullanılarak otomatikleştirilebileceğini ve yazılabileceğini hatırlamak önemlidir. JUnit entegrasyon testlerinde, org.junit.Assumeortam öğelerinin (örneğin, veritabanı bağlantısı) veya diğer koşulların kullanılabilirliğini test etmek için sınıf kullanılabilir.


0

Eğer bir TDD hastasıysanız, testleri üretim kodunu yazmadan önce yazarsınız. Tabii ki, testler derlenmeyecektir, bu yüzden önce testleri derleyin, sonra testleri geçtin.

Bunu birim testleri ile yapabilirsiniz, ancak entegrasyon veya kabul testleri ile yapamazsınız. Bir entegrasyon testini denediyseniz, işiniz bitene kadar hiçbir şey derlenmez!

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.