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;
}
DoSomething
müş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ü Log
bozulur, [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, Log
100 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, DoSomething
birim testi yeşil, çünkü Log
asla 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:
Tek bir hata birkaç özelliği kıracak ve birkaç entegrasyon testi başarısız olacaktır.
Öte yandan, aynı hata sadece bir birim testi kıracaktır.
Şimdi, iki senaryoyu karşılaştırın.
Aynı hata sadece bir birim testi kıracaktır.
- Kırık kullanan tüm özellikleriniz
Log
kırmızı
- Tüm birim testleriniz yeşil, sadece için birim testi
Log
kı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 .