Entegrasyon testleri tasarımı nasıl eleştirir?


38

JB Rainsberger'in entegre testlerle ilgili blog yazısını okudum ve entegrasyon testinin tasarımımızla ne kadar zor olduğunu merak ediyorum?

Daha büyük olan ve tasarımımızı mikro testlerin yaptığı kadar sert bir şekilde eleştirmeyen daha entegre testler yazıyoruz


3
Soru kafa karıştırıcı. "hangi şekilde bir entegrasyon testi daha zor" "" daha büyük olan ve tasarımımızı sert bir şekilde eleştirmeyen tümleşik testler "- şimdi ne olacak?
Saat


"entegrasyon testi"! = "tümleşik test". Biliyorum. Ben de sevmiyorum, ama bu kelimelerin anlamı bu. "entegrasyon testleri" = "entegrasyon noktalarını kontrol eden testler (bir şeyleri entegre etmeden)", "entegre testler" = "(daha büyük) bir şeyleri entegre eden testler ve bütünleşik bütünü tek bir şey olarak kontrol eder". Bu şekilde, bu terimler birbirinin karşıtı olur.
JB Rainsberger

Yanıtlar:


46

Mikro testler, iyi bir tasarıma öncülük edebilir . İyi küçük testler yazarak, az miktarda kodu kasten test ediyor ve boşluklarını sahte nesnelerle dolduruyorsunuz . Bu, düşük bağlanma (birbirine bağlı olmayan şeyler) ve yüksek uyum (birlikte olan şeyler birlikte kalır) ile sonuçlanır. Bu şekilde, geri dönüp değişiklik yaptığınızda, aradıklarınızdan neyin sorumlu olduğunu bulmak kolaydır ve değişikliği yaparken kırılma ihtimaliniz daha düşüktür. Bu, tüm tasarımınızı çözmez ama yardımcı olabilir.

Bu bağlamda, JB Rainsberger, bir ünite testi yazmakta zorlanıyorsanız, tasarımınızla ilgili sorunlara neden olan bir sorununuz olduğunu ve dolayısıyla testlerin tasarımı zımni eleştirdiğini belirtti. Bunun iyi bir şey olduğunu belirtti, çünkü küçük testler olmadan mimarinizi çizgide tutmaya yardımcı olmadan iyi tasarım modellerinden kurtulmanın kolay olduğunu - entegre testlerin yakalayamayacağını söyledi.

Güncelleme : Rainsberger'in not ettiği gibi, mikro testlerin birim testleriyle eşanlamlı olması niyetinde değildi. Ayrıca tam olarak ne iletişim kurduğuna dair derinlemesine bilgi verebilecek ayrıntılı bir cevap verdi.


2
Prensip olarak cevabınıza katılıyorum, ancak onu ifade ettiğiniz şekilde değil. Bu soruyu soran birinin "alaycı", "eşleşme" ve "uyum" terimlerinin ne anlama geldiğini bilmesi pek mümkün değildir ve cevabınızda bu terimleri tanımlamamışsınızdır.
Robert Harvey,

3
Bu daha iyi, ancak birim testlerine, gerçekten hak ettiklerini düşündüğümden daha fazla kredi veriyorsunuz. Birim testleri çoğunlukla kodunuzun test edilebilirliğini gösterir. Kodunuzu test edilebilir hale getirmenin otomatik olarak daha iyi bir uyum ve eşleşme özellikleri sağlayıp sağlamadığı daha az açıktır, ancak kesinlikle olumlu bir etkiye sahiptir. Ayrıca, "yüksek sorumluluk" un "tek sorumluluk ilkesi" ile karıştırıldığını düşünüyorum; uyum, "birbirine ait şeyler" anlamına gelir ( Wikipedia makalesine bakın ).
Robert Harvey,

10
Son olarak, "mikro testler" tercih edilen terim değildir. Blogcular kendi teknik terimlerini oluştururken onu seviyorum.
Robert Harvey,

2
@RubberDuck: Microtests (Yaklaşık 16.900 sonuç) vs Unit Tests (Yaklaşık 193.000.000 sonuç) . Yakınında bile değil. Birimi karıştırıp test etseniz bile, yine de 14 milyon sonuç alıyorsunuz.
Robert Harvey,

5
Lütfen "mikrotest" ve "birim testi" nı eşitlemeyin (bazı detaylar için cevabımı inceleyin); aksi halde anlatmaya çalıştığım şeyi anladığınızı hissediyorum.
JB Rainsberger

28

Son derece kısa versiyon: daha küçük testler, sistemin daha küçük parçalarını çalıştırdıkları için, programcıların yazabileceklerini doğal olarak kısıtlarlar ve bu da daha net (fark etmesi / görmemesi daha zor) geri bildirimler için bir fırsat yaratır. Bunun mutlaka daha iyi tasarıma yol açmayacağını, bunun yerine tasarım risklerini daha erken fark etme fırsatı yarattığını ekleyeyim.

Öncelikle, açıklamak gerekirse, "en küçük" derken, "küçük bir test" demek, daha fazlasını değil. Bu terimi kullanıyorum çünkü "birim testi" demek istemiyorum: "birim" teşkil ettiği konulardaki tartışmalara karışmak istemiyorum. Umurumda değil (en azından burada / şimdi değil). İki kişi muhtemelen "küçük" konusunda "birim" den ziyade daha kolay anlaşacaklardır, bu yüzden yavaş yavaş bu fikir için ortaya çıkan standart bir terim olarak "microtest" ı kullanmaya karar verdim.

Daha büyük testler, sistemin daha büyük parçalarını "eylem" bölümünde yapan testler, tasarımı açıkça veya tamamen küçük testler kadar eleştirme eğilimi göstermezler. Belirli bir test grubunu geçebilecek tüm kod tabanlarının kümesini hayal edin, bu da kodu yeniden düzenleyebileceğimi ve yine de bu testleri geçebileceğini gösterir. Daha büyük testler için bu set daha büyüktür; Daha küçük testler için bu set daha küçüktür. Farklı bir şekilde söylendiği gibi, daha küçük testler tasarımı daha fazla kısıtlar, böylece daha az tasarım geçmelerini sağlayabilir. Bu şekilde, mikro testler tasarımı daha çok eleştirebilir.

Size doğrudan duymak istemediğiniz, ancak duymanız gereken ve başkalarının rahat hissetmeyeceği bir şekilde aciliyet iletmek için size seslenmesini söyleyen bir arkadaşınızın imajını canlandırmak için "daha sert" diyorum. yapıyor. Öte yandan, bütünleşik testler sessiz kalıyorlar ve sadece çoğu zaman bunları çözmek için zamanınız ya da enerjiniz olmadığında sorunlara ipucu veriyorlar. Entegre testler tasarım problemlerini halının altına süpürmeyi çok kolaylaştırıyor.

Daha büyük testlerle (tümleşik testler gibi), programcılar çoğunlukla dikkatsizlik yüzünden başları derde sokma eğilimindedir: bir şekilde testleri geçen karışık kodlar yazma özgürlüğüne sahiptir, ancak bu kodu anlamaları bir sonraki göreve geçtiklerinde hemen kaybolur ve diğerleri karışık tasarımı okumakta zorlanıyorlar. Burada entegre testlere güvenme riski yer almaktadır. Daha küçük testlerde (mikro testler gibi), programcılar çoğunlukla aşırı spesifikasyonlarla sorun yaşamaya meyillidirler: testleri, genellikle önceki testten kopyala / yapıştır yoluyla alakasız detaylar ekleyerek, aşırı kısıtlamalar yaparlar ve böylece kendilerini nispeten hızlı bir şekilde boyarlar bir köşeye. İyi haberler: Bunları yazdıktan birkaç saat veya gün sonra, fazladan ayrıntıların testten çıkarılmasından çok daha kolay ve daha güvenli buluyorum. Hatalar gittikçe fazla belirtmek, çok daha belirgin bir şekilde hasarı daha hızlı yapar ve alarm programcısı daha önce işleri düzeltmeleri gerektiğini görür. Bunu bir güç olarak görüyorum: Sorunları daha önce fark ettim ve bu sorunları özellikler ekleme kapasitemize boğmadan önce düzeltiyorum.


Birim testlerinin gerçek kodundan ziyade alaylarına daha fazla güveniyor olması problemi hakkında ne yapıyorsunuz ki, geçtiği görünen ama aslında işe yaramayan testler sorununa yol açıyor çünkü hiç kimse alayları gerçeğe uygun tutmuyor.
Zan Lynx,

@ZanLynx Bu konuda yazı yazdım. Buradan başlayın: blog.thecodewhisperer.com/series#integrated-tests-are-a-scam
JB Rainsberger

9

İyi yazılım tasarımının birim testler ile entegrasyon testlerinden daha iyi bilgilendirildiği anlamına gelir.

İşte nedeni. Birim testleri yazmak, sizi birim test edilebilir bir kod yazmaya zorlar. Birim test edilebilir kodu, birim testi olmayan koddan daha iyi bir tasarım olma eğilimindedir.

Entegrasyon testleri, kodunuzu aynı şekilde bildirmez, çünkü yalnızca yazılımınızı birbirine bağlayan iç arabirimleri değil, yalnızca yazılımın dış katmanını test ediyorsunuzdur.

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.