Entegrasyon testi için neden bellek içi veritabanı kullanılır?

Test için kullanılan bir çok bellek içi veritabanı uygulaması gördüğümde gerçekten kafam karıştı, çünkü entegrasyonu test eden en iyi uygulamalardan, testi çalıştıran ortamın işletim sistemi de dahil olmak üzere mümkün olduğunca üretim ortamına benzemesi gerektiğini duydum. , kütüphane, veritabanı motoru vb.

Burada ne eksik?

Tipik bir yazılım geliştirme durumunda, testler iki noktada kullanılır: geliştirme sırasında ve ürünü geliştirme zinciri boyunca hareket ettirmeden önce.

İlk durum, geliştirme sırasında testler yürütmek, kısa vadeli hedeflere hizmet eder: görevleri tanımlamak (TDD'de olduğu gibi: başarısız bir test yazın, sonra geçmesini sağlayın), gerilemeleri önleyin, değişikliklerinizin başka hiçbir şeyi kırmadığından emin olun. testlerin son derece hızlı olması gerekir: ideal olarak, tüm test paketiniz 5 saniyeden daha kısa sürede çalışır ve kodlama sırasında IDE'nizin veya metin düzenleyicinizin yanındaki bir döngüde çalıştırabilirsiniz. Tanıtacağınız herhangi bir regresyon saniyeler içinde açılacaktır. Hızlı test çalışmaları, bu aşamada, gerilemelerin ve hataların% 100'ünü yakalamaktan daha önemlidir ve üretim sistemlerinin tam kopyalarında geliştirilmesi pratik (veya açıkça imkansız) olduğundan, burada mükemmel test elde etmek için gereken çabaya değmez. o. Bellek içi veritabanlarını kullanmak bir değiş tokuştur: bunlar üretim sisteminin tam kopyaları değildir, ancak test çalışmalarını 5 saniyelik sınırın altında tutmaya yardımcı olurlar; seçim benim veritabanı ile ilgili test için biraz farklı bir veritabanı kurulumu arasında ve hiçbir test arasında ise, ben ne seçtiğimi biliyorum.

İkinci durum, geliştirme zinciri boyunca kodunun taşınması Ancak yapar kapsamlı testler gerektirir. Geliştirme sürecinin bu bölümünü otomatikleştirebileceğimiz (ve gerektiğinde), çok daha yavaş testler yapabiliriz - tam bir test çalışması saatler sürse bile, gece derlemesini planlamak, dünün kod tabanının her zaman doğru bir resmine sahip olduğumuz anlamına gelir. Üretim ortamını olabildiğince doğru bir şekilde simüle etmek artık önemlidir, ancak bunu karşılayabiliriz. Bu yüzden bellek içi veritabanı dengesini yapmıyoruz: üretim sistemleriyle tam olarak aynı DBMS'nin aynı sürümünü kuruyoruz ve mümkünse test başlamadan önce gerçek üretim verileriyle dolduruyoruz.

Sanırım bu bir takas hızı / çevre ile uyumlu. Testler sık ​​sık yapılmalıdır ve bu da hızlı olmaları gerektiği anlamına gelir. Özellikle birkaç saniyeden fazla sürmemesi gereken birim testleri.

Entegrasyon testleri daha yavaş çalışacaktır, ancak hızlı olduklarında daha sık çalıştırabilirsiniz. Örneğin, her taahhütten önce. Tabii ki, tam bir ortam kadar eksiksiz değil, ama en azından eşleme katmanını, oluşturulan SQL'i, parçanın birbiriyle nasıl konuştuğunu vb. Test ediyorsunuz. Pahalı veritabanı durumunda, Herkes için lisans almanız gerekmez. Kodun% 90'ını kapsayan testlerle saatte bir kez yapılan kod testinin% 100'ünü günde bir kez veya en kötü şekilde kapsayana göre daha fazla hata yakalayabilirsiniz.

Tabii ki gerçek veritabanı ve tamamen entegre bir ortam ile test gerekir. Bu testleri sık sık uygulayamazsınız, ancak önceki testiniz zaten size güven verdiğinden, geriye kalan tek şey tuhaf platforma özgü bir hatadır.

Basit testler yapmak için, veritabanı erişim katmanını taklit etmek son derece kabul edilebilir. Diyorsun getName(), DAO alay denir ve ilk isim için "John" ve soyadı için "Smith" döndürür, onları birleştirir ve her şey mükemmel. Aslında orada bir veritabanı birim test etmek gerek.

Mantık biraz daha karmaşık hale geldiğinde işler biraz daha fazla olur. Ya "createOrUpdateUser (...)" yönteminiz varsa. Veritabanına alay ederseniz, sahte bir nesne döndürmediğinde belirli bir parametreyle belirli bir yöntemin bir kez çağrıldığını ve varolan bir nesneyi geri döndürdüğünde veritabanında farklı bir yöntem çağrıldığını doğrulayabilirsiniz. Bu, bellek veritabanında bir uzmanı döndürmenin ve bu kodu önceden yapılandırılmış verilerle test etmenin daha kolay olabileceği (özellikle zaten oradaysa) bulanık çizgiye ulaşmaya başlar.

Üzerinde çalıştığım bazı gerçek kodlarda (satış noktası) bir resumeSuspededTransaction(...)yöntemimiz vardı . Bu, işlemi veritabanından bir nesneye (ve bileşenlerine) çeker ve veritabanını günceller. Biz alay ve bir hata kodu bir yerde veritabanına gidiyor serileştirme ve serileştirme ile bir yerde gizlenmiş (biz veritabanında farklı serileştirilmiş bir tür değiştirdi).

Alaycı bize hatayı göstermedi çünkü mutlu yolunu döndürüyordu - işlemi seri hale getirin, alayda saklayın, alaydan serisini kaldırın, eşit olduklarını test edin. Ancak, bir nesneyi veritabanına önde gelen bir sıfırla serileştirdiğinizde, onları bırakıyor ve daha sonra sıfırlar olmadan bir dizeye yeniden birleştiriyordu. Biz sorun giderme yoluyla veritabanı olmadan hata yakaladı (biz orada olduğunu biliyordu bir kez noktaya zor değildi).

Daha sonra oraya bir veritabanı koyduk ve bunun yerine bellek veritabanına gidersek, hatanın bu junit testinden asla geçemeyeceğini fark ettik.

Bellek veritabanlarında avantajları vardır:

• test için hızlı bir şekilde döndürülebilir (hesaplar, tablolar ve benzerlerini ayarlamak için bir DBA'ya ihtiyaç duymadan)
• veriler bu test için önceden yapılandırılabilir
• testin bittiğinde testin geri alınması konusunda endişelenmesine gerek yoktur
• her testin bellek veritabanında kendine ait olması nedeniyle aynı anda iki testin çalışıp çalışmadığını düşünmenize gerek kalmaz
• gerçek veritabanlarına bağlantısı olmayan sistemlerde çalıştırılabilirler

Bu, kullandığınız veritabanı sistemine bağlıdır. Db sisteminiz size neredeyse% 100 API ve disk tabanlı bir veritabanı yapılandırmasıyla uyumlu bir bellek içi alternatif sunduğunda (hız ve beeing failsafe veya rota hariç), bellek içi varyantı kullanmak açıktır .

Bununla birlikte, DB sisteminizin bellek içi yapılandırma ile bellek dışı kullanım arasında önemli farklılıklar varsa, haklısınız: bu durumda entegrasyon testlerinde hata gölgeleme riski daha yüksektir. Ancak o zaman bile, DB sisteminizi ve farklılıkları iyi bildiğinize göre, bu farklılıkları kendiniz soyutlayabilirsiniz.

Layman'ın sözleriyle:

Mimarinin önemli bölümlerinin alay edilmesi, birim testleri için uygundur (ve şarttır) .

Ancak entegrasyon testi için size kesinlikle katılıyorum. Alay etme yapılmamalı ve gerçek ortamla mümkün olduğunca benzer bir ortam sağlanmalıdır.

Sonuçta, entegrasyon testleri mimarinin farklı bölümlerinin birlikte nasıl davrandığını test etmekle ilgilidir.