(Veritabanı) entegrasyon testleri kötü mü?


120

Bazı insanlar entegrasyon testlerinin her türlü kötü ve yanlış olduğunu iddia eder - her şey ünite testinden geçirilmelidir, bu da bağımlılıklarla alay etmeniz gerektiği anlamına gelir; Çeşitli sebeplerden dolayı her zaman düşkün olmadığım bir seçenek.

Bazı durumlarda, bir birim testinin hiçbir şeyi kanıtlamadığını biliyorum.

Aşağıdaki (önemsiz, saf) depo uygulamasını (PHP'de) örnek olarak alalım:

class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}

Diyelim ki bu havuzun, belirli anahtar kelimelere uyan ürünleri bulabildiğini kanıtlamak istiyorum.

Gerçek bir bağlantı nesnesiyle yapılan entegrasyon testinden kısacası, bunun gerçekten gerçek sorgular oluşturduğunu nasıl bilebilirim - ve bu sorgular gerçekte yaptıklarımı gerçekten yapar.

Bağlantı nesnesini bir birim testinde alay etmek zorunda kalırsam, yalnızca "beklenen sorguyu oluşturur" gibi şeyleri kanıtlayabilirim - ancak bu gerçekten işe yarayacağı anlamına gelmez ... yani, belki sorguyu oluşturuyor demektir. Beklerdim ama belki bu sorgu düşündüğüm şeyi yapmaz.

Başka bir deyişle, oluşturulan sorgu hakkında iddialarda bulunan, aslında değer içermeyen bir test gibi hissediyorum, çünkü findByKeyword()yöntemin nasıl uygulandığını test ediyor , ancak bu gerçekten işe yaradığını kanıtlamıyor .

Bu sorun havuzlar veya veri tabanı entegrasyonu ile sınırlı değildir - birçok durumda, bir sahte kullanım (test-double) kullanımıyla ilgili iddialarda bulunup bulunmadıklarını, sadece işlerin nasıl uygulandığını ispatladığını kanıtladığı durumlarda geçerlidir. aslında işe yarıyor.

Bu gibi durumlarla nasıl başa çıkıyorsunuz?

Böyle bir durumda entegrasyon testleri gerçekten "kötü" mü?

Bir şeyi test etmenin daha iyi olduğu fikrine kapılıyorum ve ayrıca entegrasyon testlerinin neden hepsi test edilemeyen sayısız kod yollarına neden olduğunu da anlıyorum - ancak tek amacı bir hizmet durumunda (depo gibi) başka bir bileşenle etkileşime geçmek için, entegrasyon testi olmadan bir şeyi gerçekten nasıl test edebilirsiniz?


5
Agitar.com/downloads/TheWayOfTestivus.pdf , özellikle de sayfa 6 "Test üniteden daha önemlidir" konusunu okuyun .
Doktor Brown

2
@ user61852 açıklamasında "saf" diyor, evet?
mindplay.dk

4
İş arkadaşınız, alaycı veritabanının gerçek şey gibi davrandığından nasıl emin olabilir?
Thorbjørn Ravn Andersen

12
Gerçekçi olmaya çalışıyorsun. İş arkadaşınız kurallara uymaya çalışıyor. Her zaman değer üreten testler yazınız . Uygulanamayacak olan testler için zaman harcamayın ve aşağıdakilerden birini yapmayan testler yazmayın: kodunuzun doğru olma olasılığını artırın veya sizi daha fazla korunabilir kod yazmaya zorlayın.
jpmc26

3
@ mindplay.dk: Bu paragraftaki anahtar cümle şudur: “Ama herhangi bir dogmaya sıkışıp kalmayın. Yazılması gereken testi yazın.” İş arkadaşınız dogmada sıkışmış görünüyor. Ve birisine ihtiyacınız yok Örneğinizde yazılması gereken testin ne olduğunu size açıklamak - bunu zaten biliyorsunuz.Bütün veritabanınız sorguyu anlıyorsa test etmek için sorguyu gerçek veritabanına karşı çalıştırmanız gerektiği açıktır - hiçbir sahte size söyleyemez bu
Doktor Brown

Yanıtlar:


129

İş arkadaşınız, birim testine tabi tutulabilecek her şeyin birim testine tabi tutulması gerektiği konusunda haklıdır ve özellikle de karmaşık dış hizmetler üzerine basit paketler yazarken, birim testlerinin sizi yalnızca bugüne kadar ve daha ileriye götüreceği konusunda haklısınız.

Test hakkında düşünmenin yaygın bir yolu, test piramidi gibidir . Bu, genellikle Agile ile bağlantılı bir kavram ve Martin Fowler (onu Agile ile Başarılı Olmada Mike Cohn'a bağlayan ), Alistair Scott ve Google Test Blog'u da dahil olmak üzere pek çok konuda yazdı .

        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)

Buradaki kavram, hızlı çalışan, esnek birim testlerinin test sürecinin temeli olduğu şeklindedir - sistem / entegrasyon testlerinden daha fazla odaklanmış birim testi ve uçtan uca testlerden daha fazla sistem / entegrasyon testi olması gerekir. En üste yaklaştıkça, testler daha fazla zaman / kaynak almak eğilimindedir, daha kırılganlık ve lapa lapa olma eğilimindedir ve hangi sistemin veya dosyanın bozulduğunu belirleme konusunda daha az spesifiktir ; Doğal olarak, "en ağır" olmaktan kaçınmak tercih edilir.

Bu noktada, entegrasyon testleri kötü değildir , ancak bunlara yoğun bir şekilde bağlı kalmak, tek tek bileşenlerinizi test etmesi kolay olacak şekilde tasarlamadığınızı gösterebilir. Unutmayın, buradaki amaç, minimum kırılabilir sistemleri de dahil ederek ünitenizin kendi özelliğine göre performans gösterdiğini test etmektir : Bir bellek içi veritabanını denemek isteyebilirsiniz (ki bu, alaylı çiftlerin yanında birim test dostu bir test olarak sayıyorum). ) örneğin ağır kenar durum testi için, ve ana durumların sistem monte edildiğinde çalıştığını tespit etmek için gerçek veritabanı motoruyla birkaç entegrasyon testi yazın.


Bir yandan not olarak, yazdığınız alayların bir şeyin nasıl uygulandığını değil, nasıl uygulandığını test ettiğini söylemiştiniz . Bu antipattern için bir şey: Uygulamasının kusursuz bir aynası olan bir test gerçekten hiçbir şeyi test etmiyor. Bunun yerine, her sınıfın veya yöntemin , gereksinim duyduğu soyutlama veya gerçekçilik düzeyinde, kendi özelliğine göre davrandığını test edin .


13
+1 "Uygulamasının kusursuz bir aynası olan bir test gerçekten hiçbir şeyi test etmiyor." Hepsi çok yaygın. Buna Doppelganger Antipattern diyorum .
dodgethesteamroller

6
Bağlam kaynaklı test hareketi olan, kontrari bir yazılım QA okulu kısmen, Test Piramidi gibi kullanışlı herhangi bir genel kuralın mevcut olduğuna itiraz etmeye adamıştır. Özellikle, hareketin seminal metinleri , entegrasyon testlerinin diğer test türlerinden çok daha değerli olduğu birçok örnek verir (çünkü sistemi bağlamda, sistem olarak test ederler ) ....
dodgethesteamroller

7
... sonuç olarak, Fowler ve ark., entegrasyon testlerine ve kullanıcı kabul testlerine daha az çaba harcanması gerektiğini savundukları için, sağlam ve bakımı kolay bir şekilde yazmak için çok zor oldukları için, neden sadece fiili bir mazeret sağladıklarını onlar daha yüksek düzeylerde iyi nasıl test çözemedim.
dodgethesteamroller

1
@dodgethesteamroller Öyle bir "karşıt okul" hakkında derinlemesine tartışmalar muhtemelen kendi cevaplarına en uygun olanı. Şahsen, Google Test Blogunun, bağlam içi sistem testlerinin yanı sıra hızlı ve kapsamlı bir şekilde otomatikleştirilmiş otomatik testlerin erdemlerini tanımlayan oldukça iyi bir iş çıkardığını biliyorum . Belirsiz buluyorsanız, test piramidini burada mühendis olarak düşünmeyi bırakmak için bir bahane olarak değil, faydalı bir model veya başlangıç ​​noktası olarak listeleyeceğim.
Jeff Bowman

1
En çok tercih edilenlerin hiyerarşi ve entegrasyon testlerine oranı hakkında sunum: vimeo.com/80533536 Çok iyi açıklanmıştır.
szalski

88

İş arkadaşlarımdan biri entegrasyon testlerinin her türlü kötü ve yanlış olduğunu iddia ediyor - her şey birim testine tabi tutulmalı,

Bu, antibiyotiklerin kötü olduğunu söylemek gibi bir şey - her şey vitaminlerle tedavi edilmelidir.

Birim testleri olamaz şeyi yakalamak - Bir bileşen nasıl çalıştığını sadece sınamak kontrollü bir ortamda . Entegrasyon testleri, her şeyin birlikte çalıştığını , bunun yapılması daha zor, ama sonuçta daha anlamlı olduğunu doğrular .

İyi ve kapsamlı bir test süreci, her iki test türünü de kullanır - iş kurallarını doğrulamak için birim testleri ve bağımsız olarak test edilebilecek diğer şeyler ve her şeyin birlikte çalıştığından emin olmak için entegrasyon testleri.

Gerçek bir bağlantı nesnesiyle yapılan entegrasyon testinden kısacası, bunun gerçekten gerçek sorgular oluşturduğunu nasıl bilebilirim - ve bu sorgular gerçekte yaptıklarımı gerçekten yapar.

Bunu birim seviyesinde test edebilirsin . Sorguyu çeşitli parametrelerle çalıştırın ve beklediğiniz sonuçları alıp almadığınızı görün. Verilmesi, herhangi bir değişikliğin tekrar "gerçek" koduna kopyalanması / yapıştırılması anlamına gelir. ama yok başka bağımlılıkları sorgu bağımsız test edebilirsiniz.


Veritabanında belirli veriler bulunup bulunmadığını test etmiyor musunuz?
Tulains Córdova

Muhtemelen - ancak filtrelerinizin, karmaşık birleşmelerinizin, vb. Çalıştığını da test ediyor olabilirsiniz. Örnek sorgu muhtemelen "birim testleri" için en iyi aday değil, karmaşık birleşimler ve / veya toplamalardan biri olabilir.
D Stanley

Evet - kullandığım örnek, belirtildiği gibi önemsizdir; gerçek bir depo, her tür karmaşık arama ve sıralama seçeneğine sahip olabilir, örneğin bir sorgu oluşturucu vb. kullanma
mindplay.dk

2
İyi cevap, ancak birim sınamalarının hızlı olduğundan emin olmak için DB'nin bellekte olması gerektiğini eklerdim.
BЈовић

3
@ BЈовић: Maalesef, bu her zaman mümkün olmayabilir, çünkü maalesef iki uyumlu DB yok ve hepsi bellekte çalışmıyor. Ticari DB'ler için lisans sorunları da var (herhangi bir makinede çalıştırma lisansınız olmayabilir), ...
Matthieu M.

17

Birim testleri tüm hataları yakalamaz. Fakat diğer test türleriyle kıyaslandığında daha ucuzdur ve yeniden çalışırlar. Birim testleri, orta değer ve düşük-orta maliyet kombinasyonu ile doğrulanır.

İşte farklı testler için hata tespit oranlarını gösteren bir tablo.

görüntü tanımını buraya girin

kaynak: s.470 kodunda tamamlandı 2 ile McConnell


5
Bu veri 1986 yılında toplandı . Bu otuz yıl önceydi . 1986'da yapılan birim testleri bugün olanlar değildi. Bu verilere kuşkuyla bakarım. Söylemeye gerek yok, birim testleri bugüne kadar herhangi bir taahhüt edilmeden önce hatayı tespit eder , bu yüzden bildirilmeleri şüphelidir.
RubberDuck

3
@RubberDuck Bu tablo 2006 tarihli bir kitaptan alınmıştır ve 1986, 1996, 2002 tarihli verilere dayanmaktadır (eğer dikkatli bakarsanız). Kaynaklardaki veri toplama protokollerine bakmadım, bir hatayı izlemeye ne zaman başladıklarını ve nasıl raporlandıklarını söyleyemem. Bu çizelge biraz eski olabilir mi? O olabilir. Geçen Aralık ayında bir seminerdeydim ve eğitmen entegrasyon testlerinin birim testlerden daha fazla hata bulduğunu belirtti (2, iirc faktörü ile). Bu çizelge aynı olduklarını söylüyor.
Nick Alexeev

13

Hayır, fena değiller. Umarım, bir birim ve entegrasyon testleri olmalıdır. Geliştirme döngüsünde farklı aşamalarda kullanılırlar ve çalıştırılırlar.

Birim Testleri

Ünite testleri, derleme sunucusunda ve yerel olarak, kod derlendikten sonra çalıştırılmalıdır. Herhangi bir ünite testi başarısız olursa, testler düzeltilinceye kadar kod derlemesinin başarısız olması veya yapılmaması gerekir. Birim testlerinin izole edilmesini istememizin nedeni, derleme sunucusunun tüm testleri tüm bağımlılıklar olmadan çalıştırabilmesini istememizdir. Daha sonra, gerekli tüm karmaşık bağımlılıklar olmadan yapıyı çalıştırabiliriz ve çok hızlı bir şekilde çalışan çok sayıda test yaptık.

Yani, bir veritabanı için, şöyle bir şey olmalı:

IRespository

List<Product> GetProducts<String Size, String Color);

Artık IRepository'nin gerçek uygulaması, ürünleri elde etmek için veri tabanına gidecektir, ancak birim testleri için, her türlü ürün listesini simüle edebileceğimizden, bir Actaul veritabanı olmadan ihtiyaç duyulan tüm testleri yürütmek için, bir IRepository ile sahte bir sahneyi aştırabiliriz. sahte örneğinden döndürülüyor ve herhangi bir iş mantığını sahte verilerle test ediyor.

Entegrasyon Testleri

Entegrasyon testleri tipik olarak sınır geçiş testleridir. Bu testleri dağıtım sunucusunda (gerçek ortam), sanal alanda ve hatta yerel olarak (sanal alanda işaretlenmiş) çalıştırmak istiyoruz. Derleme sunucusunda çalıştırılmazlar. Yazılım çevreye dağıtıldıktan sonra, tipik olarak bunlar dağıtım sonrası etkinlik olarak çalıştırılır. Komut satırı yardımcı programları aracılığıyla otomatikleştirilebilirler. Örneğin, çağırmak istediğimiz tüm entegrasyon testini kategorize edersek, nUnit'i komut satırından çalıştırabiliriz. Bunlar aslında gerçek veritabanı çağrısı ile gerçek depoyu çağırır. Bu tür testler şunlara yardımcı olur:

  • Çevre Sağlığı İstikrarına Hazırlık
  • Gerçek olanı test etmek

Bu testler bazen kurulum ve / veya yırtıp atmamız gerekebileceğinden zorlaşır. Bir ürün eklemeyi düşünün. Muhtemelen ürünü eklemek istiyoruz, eklenip eklenmediğini görmek için sorguya sokuyoruz ve sonra tamamladıktan sonra onu kaldırıyoruz. 100'lerin veya 1000'lerin "entegrasyon" ürününü eklemek istemiyoruz, bu yüzden ek kurulum gereklidir.

Entegrasyon testleri bir ortamı doğrulamak ve gerçek şeylerin çalıştığından emin olmak için oldukça değerli olabilir.

Bir ikisinde de olmalı.

  • Her yapı için birim testlerini çalıştırın.
  • Her dağıtım için entegrasyon sınamalarını çalıştırın.

Taahhüt ve zorlamak yerine her yapı için entegrasyon testi çalıştırmanızı tavsiye ederim. Ne kadar süreceklerine bağlı olarak, aynı zamanda onları birçok nedenden dolayı hızlı tutmak da iyi bir fikirdir.
artbristol

@ArtBristol - Genelde, derleme sunucumuz tam bir ortam bağımlılığına sahip değildir, bu nedenle entegrasyon testlerimizi burada yapamayız. Fakat eğer orada entegrasyon testlerini yapabilirseniz, bunun için gidin. Kurulumu doğrulamak için entegrasyon testi için kullandığımız derlemeden sonra oluşturulmuş bir dağıtım sanal alanımız var. Ancak her durum farklı.
Jon Raynor

11

Veritabanı entegrasyon testleri fena değil. Dahası, onlar gerekli.

Muhtemelen başvurunuzu katmanlara ayırmışsınızdır ve bu iyi bir şey. Komşu katmanları alay ederek her katmanı izolasyonda test edebilirsiniz ve bu da iyi bir şey. Fakat ne kadar soyutlama katmanı yarattığınızın önemi yok, bir noktada kirli işleri yapan bir katman olması gerekiyor - aslında veritabanıyla konuşun. Test etmediğin sürece, hiç test etmiyorsun . Eğer katman test ederseniz n tabaka alay yoluyla n-1 Eğer varsayımı değerlendirdiklerini katman n çalışır şartıyla katman n-1 eser. Bunun çalışması için bir şekilde katman 0'ın işe yaradığını ispatlamanız gerekir.

Teoride, test veritabanını bir araya getirebilirken, oluşturulan SQL'i ayrıştırıp yorumlayarak, anında test veritabanı oluşturmak ve onunla konuşmak çok daha kolay ve daha güvenilirdir.

Sonuç

Özet Deposu , Ethereal Nesne-İlişkisel Eşleştiricisi , Jenerik Aktif Kayıt , Teorik Kalıcılık katmanlarınızı test eden ünitenin sağladığı güven nedir, sonunda SQL'iniz sözdizimi hatası içeriyorsa?


Sizinkine benzer bir cevap eklemeyi düşünüyordum ama daha iyi söylediniz! Tecrübelerime göre, veriyi alan ve depolayan bazı testler yapmak beni çok üzdü.
Daniel Hollinrake

Veritabanı entegrasyon testleri olsa kötü. Ci / cd hattınızda uygun bir veritabanınız var mı? Bu bana oldukça karmaşık görünüyor. Veri tabanıyla alay etmek ve bunu kullanmak için bir soyutlama katmanı oluşturmak çok daha kolaydır. Sadece bu çok daha zarif bir çözüm değil, mümkün olduğu kadar hızlı. Birim testlerinin hızlı olması gerekir. Veritabanınızı test etmek, en küçük testlerinizi önemli ölçüde yavaşlatamayacak kadar yavaşlatır. Unittests, binlerce kişiye sahip olsalar bile, yapılması> 10 dakika sürmemelidir.
David

@David ci / cd hattınızda mevcut bir veritabanı var mı? Tabii, bu oldukça standart bir özellik . BTW, birim testleri yerine entegrasyon testlerini desteklemiyorum - Birim testleri ile birlikte entegrasyon testlerini savunuyorum . Hızlı birim testleri önemlidir, ancak veritabanları sahte etkileşimlerle birim testlerine dayanmak için çok karmaşıktır.
el.pescado

@ el.pescado katılmıyorum zorundayım. Veri tabanı iletişiminiz bir soyutlama katmanının arkasındaysa, alay etmek gerçekten kolaydır. Hangi nesnenin döneceğine sadece karar verebilirsiniz. Ayrıca, bir şeyin standart olması da onu iyi bir şey yapmaz.
David

@David Veritabanına nasıl yaklaştığınıza bağlı olduğunu düşünüyorum. Uygulama detayı mı yoksa sistemin hayati bir parçası mı? (Ben ikincisine yaslanıyorum) . Veritabanını basit bir veri saklama alanı olarak görürseniz, evet, entegrasyon testleri olmadan yapabilirsiniz. Ancak, veritabanında herhangi bir mantık varsa - kısıtlamalar, tetikleyiciler, yabancı anahtarlar, işlemler veya veri katmanınız düz ORM yöntemleri yerine özel SQL kullanıyorsa, birim testlerinin tek başına yeterli olmayacağını düşünüyorum.
el.pescado

6

İkisine de ihtiyacın var.

Örneğinizde, bir veritabanını belirli bir durumda test ediyorsanız, findByKeywordyöntem çalıştırıldığında verileri geri alırsanız, bunun iyi bir entegrasyon testi olmasını beklersiniz.

Bu findByKeywordmetodu kullanan başka bir kodda , teste neyin beslendiğini kontrol etmek istersiniz, böylece testiniz için null'ları veya doğru kelimeleri ya da veri tabanına olan bağımlılığı alamazsanız, testinizin tam olarak ne olacağını bilirsiniz. al (ve bir veritabanına bağlanma ve içindeki verilerin doğru olduğundan emin olmanın genel giderini kaybedersin)


6

Bahsettiğiniz blog makalesinin yazarı , esasen, bütünleşik testlerden doğabilecek potansiyel karmaşıklıkla ilgilidir (çok ayrıntılı ve kategorik bir şekilde yazılmasına rağmen). Bununla birlikte, entegre testler mutlaka kötü değildir ve bazıları saf birim testlerinden daha faydalıdır. Bu gerçekten uygulamanızın içeriğine ve ne test etmeye çalıştığınıza bağlıdır.

Günümüzde pek çok uygulama, veritabanı sunucusu çökerse basitçe işe yaramazdı. En azından, test etmeye çalıştığınız özellik bağlamında düşünün.

Bir yandan, test etmeye çalıştığınız şey veritabanına bağlı değilse veya hiç bir şekilde bağımlı olmayacaksa, testinizi kullanmayı bile deneymeyecek şekilde yazın. veritabanı (yalnızca gerektiği gibi sahte veriler sağlayın). Örneğin, bir web sayfasını sunarken bazı kimlik doğrulama mantığını test etmeye çalışıyorsanız (örneğin), bunu tamamen DB'den ayırmak iyi bir şeydir (kimlik doğrulama için DB'ye güvenmediğinizi varsayarak veya oldukça kolay alay edebilirsiniz).

Öte yandan, doğrudan veritabanınıza dayanan ve gerçek bir ortamda işe yaramayacak bir özellik varsa, veritabanı kullanılamıyorsa, DB'nin müşteri kodunuzda (örneğin, bunu kullanan katmanı kullanarak DB) mutlaka mantıklı değil.

Örneğin, uygulamanızın bir veritabanına (ve muhtemelen belirli bir veritabanı sistemine) dayanacağını biliyorsanız, bunun için veritabanı davranışını alay etmek genellikle zaman kaybı olur. Veritabanı motorları (özellikle RDBMS) karmaşık sistemlerdir. Birkaç SQL hattı gerçekten çok fazla iş yapabilir, bu da benzetilmesi zor olacaktır (aslında, eğer SQL sorgunuz birkaç satır uzunsa, muhtemelen Java / PHP / C # / Python satırlarına ihtiyacınız olacak) dahili olarak aynı sonucu elde etmek için gereken kod):: DB'ye daha önce uyguladığınız mantığın çoğaltılması bir anlam ifade etmiyor ve bu test kodunu kontrol etmek kendi başına bir sorun haline geliyor.

Buna zorunlu olarak bir bütünleşik test - bütünleşik test problemi gibi davranmam , bunun yerine test edilenin kapsamına bakmam gerekir. Ünite ve entegrasyon testlerinin genel sorunları devam etmektedir: makul derecede gerçekçi bir test verisi ve test senaryosuna ihtiyacınız var, ancak testlerin hızlı bir şekilde yapılması için yeterince küçük bir şey.

Veritabanını sıfırlama ve test verileriyle yeniden doldurma zamanı, göz önünde bulundurulması gereken bir husustur; Bunu genellikle sahte kodun yazılması için geçen süreye göre değerlendiriyorsunuz (ki sonunda da sürdürmeniz gerekiyordu).

Dikkate alınması gereken bir diğer nokta, uygulamanızın veritabanına olan bağımlılık derecesidir.

  • Uygulamanız basit bir yapılandırma ayarıyla herhangi bir RDBMS arasında geçiş yapmanıza olanak tanıyan bir soyutlama katmanına sahip olduğunuz bir CRUD modelini izlerse, olasılıkla kolayca sahte bir sistemle çalışabilirsiniz (muhtemelen bulanıklaştırma) Bellek içi RDBMS kullanarak birim ve tümleşik test arasındaki hat).
  • Uygulamanız daha karmaşık bir mantık kullanıyorsa, örneğin SQL Server, MySQL, PostgreSQL'e (örneğin) özgü bir şey kullanıyorsa, o zaman bu sistemi kullanan bir sınava sahip olmak genellikle daha mantıklı olur.

"Günümüzde pek çok uygulama, veritabanı sunucuları çökerse basitçe işe yaramaz" - bu gerçekten önemli bir nokta!
el.pescado

SQL ile alay etmek için başka bir dil kullanmak gibi karmaşık alaycılığın sınırlarının iyi bir açıklaması. Test kodu kendi başına test edilmesi gerektiği gibi göründüğü kadar karmaşık hale geldiğinde, bu bir QA kokusu.
dodgethesteamroller 12:15

1

Böyle bir ünite testini tamamlanmamış olarak düşünmekte haklısın. Eksiklik alay konusu veritabanı arayüzündedir. Bu tür saf alaycının beklentisi veya iddiaları eksik.

Bunu tamamlamak için, test edilen konu tarafından yayılan SQL ifadesinin beklenen işlemlerle sonuçlanacağını garanti edecek bir SQL kuralları motoru yazmak veya entegre etmek için yeterli zaman ve kaynakları ayırmanız gerekir .

Bununla birlikte, alay etmeye genellikle unutulan ve biraz pahalı olan alternatif / yoldaş "sanallaştırma" dır .

Tek bir işlevi sınamak için geçici, bellek içi ancak "gerçek" bir DB örneği döndürebilir misiniz? Evet ? orada, kaydedilen ve alınan gerçek verileri kontrol eden daha iyi bir teste sahipsiniz.

Şimdi, bir kişi bir birim testini bir entegrasyon testine dönüştürdüğünüzü söyleyebilir. Ünite testleri ve entegrasyon testleri arasında sınıflandırmak için çizgiyi nasıl çizeceğiniz konusunda çeşitli görüşler vardır. IMHO, "birim" keyfi bir tanımdır ve ihtiyaçlarınızı karşılamalıdır.


1
bu sadece birkaç saat önce gönderilen bu önceki cevabın verdiği ve açıkladığı noktaları tekrar ediyor gibi görünüyor
gnat

0

Unit Testsve Integration Testsbirbirlerine ortogonaldirler . Yapmakta olduğunuz uygulama hakkında farklı bir görünüm sunarlar. Genellikle ikisini de istiyorsun . Fakat zamanın amacı, ne tür testler yapmak istediğinize göre değişir.

İstediğin en sık Unit Tests. Birim testleri, test edilen kodun küçük bir kısmına odaklanır - tam olarak a denilen unitşey okuyucuya bırakılır. Ancak amaç basittir: kodunuzun ne zaman ve nerede bozulduğuna dair hızlı geri bildirim almak . Açıkçası , gerçek bir DB çağrısının nono olduğu söyleniyor .

Öte yandan, veritabanları olmadan sadece zor şartlar altında test edilebilecek şeyler var . Belki de kodunuzda bir yarış durumu vardır ve bir DB'ye yapılan çağrı unique constraint, yalnızca sisteminizi kullanıyorsanız atılabilecek bir ihlale yol açar . Ancak bu tür testler pahalıdır , bu kadar sık ​​olarak yapamazsınız (ve istemezsiniz) unit tests.


0

.Net dünyasında, bir test projesi oluşturma ve kodlama / hata ayıklama / test etme turu eksi kullanıcı arayüzünü test etme yöntemi olarak testler oluşturma alışkanlığım var. Bu gelişmem için etkili bir yol. Her yapı için tüm testleri yapmakla ilgilenmiyordum (çünkü geliştirme iş akışımı yavaşlatıyor), ancak bunun daha büyük bir ekip için faydasını anlıyorum. Yine de, bir kodlamadan önce tüm testlerin çalıştırılması ve geçilmesi gerektiğine dair bir kural koyabilirsiniz (testlerin çalışması uzun sürerse, veritabanına gerçekten çarpıldığı için).

Veri erişim katmanını (DAO) çıkarmak ve aslında veritabanına vurmak değil, yalnızca benim istediğim ve alıştığım gibi kodlamama izin vermiyor, aynı zamanda gerçek kod tabanının büyük bir bölümünü özlüyor. Veri erişim katmanını ve veritabanını tam olarak test etmiyorsanız ve sadece taklit ediyorsanız ve daha sonra işleri alay etmek için çok zaman harcıyorsanız, kodumu sınamak için bu yaklaşımın kullanışlılığını kavrayamıyorum. Tek bir testle daha büyük bir parça yerine küçük bir parçayı test ediyorum. Benim yaklaşımımın bir entegrasyon testinin çizgileri boyunca daha fazla olabileceğini anlıyorum, ancak aslında bir ve bir entegrasyon testini gerçekten yazdıysanız, sahte ile yapılan birim testinin gereksiz bir zaman kaybı olduğu görülüyor. Aynı zamanda geliştirmek ve hata ayıklamak için iyi bir yoldur.

Aslında, bir süredir TDD ve Behavior Driven Design (BDD) 'nin farkındayım ve onu kullanmanın yollarını düşünüyorum, ancak geriye dönük ünite testleri eklemek zor. Belki de yanılıyorum ama veritabanına dahil olmak için uçtan uca daha fazla kod içeren bir test yazmak, daha fazla kod içeren ve testler yazmak için daha verimli bir yol olan yazmak için çok daha eksiksiz ve daha yüksek öncelikli bir test gibi görünüyor.

Aslında, etki alanına özgü bir dille (DSL) uçtan uca test etmeye çalışan Behavior Driven Design (BDD) gibi bir şeyin yolunda olması gerektiğini düşünüyorum. .Net dünyasında SpecFlow var, ancak Salatalık ile açık kaynak olarak başladı.

https://cucumber.io/

Veri erişim katmanını alay ederek yazdığım ve veritabanına vurmadığım testin gerçek kullanışlılığından gerçekten etkilenmedim. Döndürülen nesne veritabanına çarpmadı ve verilerle doldurulmadı. Doğal olmayan bir şekilde alay etmek zorunda kaldığım tamamen boş bir cisimdi. Sadece zaman kaybı olduğunu düşünüyorum.

Yığın Taşması'na göre, alay, gerçek nesnelerin birim testine dahil edilmesi pratik olmadığında kullanılır.

https://stackoverflow.com/questions/2665812/what-is-mocking

"Alay etmek esas olarak ünite testlerinde kullanılır. Test edilen bir nesnenin diğer (karmaşık) nesnelere bağımlılığı olabilir. Test etmek istediğiniz nesnenin davranışını yalıtmak için, diğer nesnelerin yerine gerçek nesnelerin davranışını taklit eden değiştirmeleri uygulayabilirsiniz. Bu, gerçek nesnelerin birim testine dahil etmek için pratik olmadığında faydalıdır. "

Argümanım, eğer uçtan uca bir şey kodluyorsam (web kullanıcı arayüzünden iş katmanına veri erişim katmanına veri tabanına, gidiş dönüş), bir geliştirici olarak kontrol etmeden önce bu gidiş dönüş akışını test edeceğim. Kullanıcı arayüzünü kesip bir testten başlayarak bu akışı ayıklayıp test edersem, kullanıcı arayüzünün dışındaki her şeyi test ederim ve kullanıcı arayüzünün beklediğini tam olarak geri veririm. Elimde kalan tek şey UI'ye istediğini göndermek.

Doğal gelişim iş akışımın bir parçası olan daha kapsamlı bir testim var. Bana göre, bu gerçek kullanıcı spesifikasyonlarının mümkün olduğunca uçtan uca test edilmesini kapsayan en yüksek öncelikli test olmalıdır. Başka hiçbir ayrıntılı test oluşturmadıysam, en azından istediğim işlevselliğin işe yaradığını ispatlayan bu bir daha tam testim var.

Stack Exchange'in kurucu ortağı% 100 birim test kapsamına sahip olmanın faydaları konusunda ikna olmuyor. Ben de değilim. Her gün bir grup veritabanı alayını sağlamanın üzerine veritabanına isabet eden daha eksiksiz bir "entegrasyon testi" alırdım.

https://www.joelonsoftware.com/2009/01/31/from-podcast-38/


ünite ve entegrasyon testleri arasındaki farkı anlamadığınız çok açıktır
BЈовић

Projeye bağlı olduğunu düşünüyorum. Bir geliştiricinin test eksikliği ve regresyon testlerinden genel olarak sorumlu olduğu daha az kaynağa sahip daha küçük projelerde, test edicilerin yetersizliği ve dokümantasyonun kodla senkronize tutulması nedeniyle, test yapmak için zaman harcayacak olursam, bana paranın karşılığını en iyi şekilde verir. Bir taşla mümkün olduğunca çok kuş öldürmek istiyorum. Mantığımın ve hatalarımın çoğu rapor üreten veritabanı saklı yordamlardan veya ön uç JavaScript'ten geliyorsa, orta kademede tam birim test kapsamına sahip olmak pek yardımcı olmuyor.
user3198764

-1

Dış bağımlılıklar alay etmeli çünkü onları kontrol edemezsiniz (entegrasyon test aşamasında geçebilirler ancak üretimde başarısız olabilirler). Sürücüler başarısız olabilir, veritabanı bağlantıları herhangi bir nedenden ötürü başarısız olabilir, ağ sorunları olabilir. Entegrasyon testlerinin yapılması ekstra bir güven vermez, çünkü bunlar çalışma zamanında meydana gelebilecek sorunlardır.

Gerçek birim testleriyle, sanal alanın sınırları dahilinde test yapıyorsunuz ve net olmalıdır. Bir geliştirici QA / PROD'da başarısız olan bir SQL sorgusu yazdıysa, o zamandan önce bir kez bile test etmedikleri anlamına gelir.


+ 1'i "kontrol edemezsiniz (entegrasyon test aşamasında geçebilirler ancak üretimde başarısız olabilirler") .
Tulains Córdova

Sen edebilirsiniz derecesini satisfactionary için onları kontrol.
el.pescado

Amacını anlıyorum, ama bunun bugün olduğundan daha doğru olduğunu düşünüyorum. Otomasyon ve araçlarla (Docker gibi), entegrasyon test takımları için tüm ikili / sunucu bağımlılıklarınızın kurulumunu doğru ve güvenilir bir şekilde çoğaltabilir ve tekrarlayabilirsiniz. Tabii ki, evet, fiziksel donanım (ve üçüncü taraf hizmetleri vb.) Başarısız olabilir.
mindplay.dk

5
Kesinlikle aynı fikirde değilim. Sen (ek) entegrasyon testleri yazmalıyım çünkü Extenal bağımlılıklar başarısız olabilir. Dış bağımlılıkların kendi tuhaflıkları olabilir, bu da her şeyle alay ettiğinizde büyük olasılıkla özleyeceğiniz bir şeydir.
Paul Kertscher

1
@PaulK, kabul edildiği gibi işaretlemek için hangi cevabı düşünmeye devam ediyor, ancak aynı sonuca yöneliyorum.
mindplay.dk
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.