Soruyu şaka yollu bir şekilde yazdım çünkü "duruma bağlı" olduğundan eminim ama bazı sorularım var.
Çok derin bağımlılık katmanlarına sahip yazılımlarda çalışan ekibim, her bir kod modülünü altındaki bağımlılıklardan ayırmak için oldukça kapsamlı bir şekilde alay kullanmaya başladı.
Bu nedenle Roy Osherove'un bu videoda sadece% 5 gibi bir şeyle alay etmeniz gerektiğini önerdiğine şaşırdım . Sanırım% 70-90 arasında bir yerde oturuyoruz. Ben de zaman zaman benzer başka rehberler gördüm .
Neye gerçekten farklı isimler verilmesi gerektiği kadar farklı olan iki "entegrasyon testi" kategorisi olarak düşündüğümü tanımlamalıyım: 1) Birden fazla kod modülünü entegre eden proses içi testler ve 2) Konuşan proses dışı testler veritabanları, dosya sistemleri, web hizmetleri, vb.
Okuduğum topluluk rehberliğinin çoğu, çok sayıda yalıtılmış, ince taneli ünite testini ve az sayıda kaba taneli uçtan uca entegrasyon testini tercih etmenizi önerir, çünkü ünite testleri size tam olarak nerede olduğu konusunda kesin geri bildirim sağlar regresyonlar yaratılmış olabilir, ancak kurulumu zor olan kaba testler aslında sistemin uçtan uca işlevselliğini doğrulamaktadır.
Bu göz önüne alındığında, bu ayrı kod birimlerini izole etmek için alaycılığın oldukça sık kullanılması gerekli görünmektedir.
Aşağıdaki gibi bir nesne modeli verilmiştir:
... Ayrıca, uygulamamızın bağımlılık derinliğinin bu görüntüye sığabileceğimden çok daha derine ineceğini, böylece 2-4 katmanı ve 5-13 katmanı arasında birden çok N katmanı olduğunu düşünün.
Birim 1'de yapılan basit mantıksal kararları test etmek istersem ve her bağımlılık kod modülüne yapıcıya enjekte edilirse, örneğin 2, 3 ve 4 modül 1'e yapıcı enjekte edilir. görüntü, ben çok 2, 3 ve 4 sahte 1 enjekte ediyorum.
Aksi takdirde, 2, 3 ve 4 numaralı somut örnekler oluşturmam gerekirdi. Bu, bazı ek yazımlardan daha zor olabilir. Genellikle 2, 3 ve 4, tatmin etmek için zor olabilecek yapıcı gereksinimlerine sahip olacak ve grafiğe (ve projemizin gerçekliğine göre), inşaatçılarını tatmin etmek için N'den 13'e kadar somut örnekler oluşturmam gerekecek. 2, 3 ve 4.
Bu durum belirli bir şekilde davranmak için 2, 3 veya 4'e ihtiyacım olduğunda daha zorlaşıyor, böylece # 1'deki basit mantıksal kararı test edebiliyorum. Tüm nesne grafiğini / ağacını bir kerede anlamam ve "zihinsel olarak akıl yürütmem" gerekebilir. MyMockOfModule2.Setup (x => x.GoLeftOrRight ()) yapmak genellikle çok daha kolay görünüyor. İade (yeni Sağ ()); modül 2 sağa gitmesini söylediğinde modül 1'in beklendiği gibi yanıt verdiğini test etmek için.
2 ... N ... 13 somut örneklerini hep birlikte test edersem, test kurulumları çok büyük ve çoğunlukla çoğalırdı. Test başarısızlıkları, regresyon başarısızlıklarının yerlerini belirlemek için çok iyi bir iş yapmayabilir. Testler bağımsız olmazdı ( başka bir destekleyici bağlantı ).
Kabul edilirse, alt katmanın etkileşim tabanlı olmaktan ziyade duruma dayalı test yapılması genellikle mantıklıdır, çünkü bu modüllerin nadiren başka bağımlılıkları vardır. Ancak, en altta yer alan herhangi bir modülü izole etmek için tanım gereği alay etmek neredeyse gerekli görünmektedir.
Tüm bunlar göz önüne alındığında, kimse neyi kaçırdığımı söyleyebilir mi? Ekibimiz alayları gereğinden fazla mı kullanıyor? Ya da, tipik birim test kılavuzunda, çoğu uygulamadaki bağımlılık katmanlarının, tüm entegre kod modüllerinin bir araya getirilmesinin gerçekten makul olacağı kadar makul olacağına dair bir varsayım var mı (bizim durumumuzu "özel" yapıyor)? Ya da belki de farklı bir şekilde, ekibimiz sınırlı bağlamlarımızı yeterince sınırlamıyor mu?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- Bu.