Test verilerini nerede saklamalıyım?

Gerçek veri setlerinden küçük parçacıklar kullanan daha küçük birim testlerim var. Programımı birçok nedenden ötürü tam veri kümelerine karşı test etmek istiyorum. Tek sorun, tek bir gerçek veri kümesinin yaklaşık ~ 5GB olmasıdır. Git depolarının depolayabileceği şeyler için sabit sayılar bulamadım ama bu çok fazla gözüküyor.

Bu Programcılar yazısına göre, projeyi depoda test etmek için gereken tüm verilerimi saklamalıyım.

Ekibimin benimsediği çözüm, projenin test verilerimizi tutan ağa bağlı bir dosya sistemine giden yolu içeren bir dosyaya sahip olmasıdır. Dosya Git yoksayılır.

Bunun iki nedenden dolayı kusurlu bir çözüm olduğunu hissediyorum. NAS çalışmadığında, yavaşsa veya tam test yapamayacağımızdan daha düşük olduğunda. İkinci neden, birisi bir havuzu ilk kez klonladığında, birim testleri başarısız olur, bu nedenle belirli bir ada sahip şeylerin nasıl bağlanacağını ve test yolu dosyasını oluşturmak için kullanılan sözdizimini bulmaları gerekir.

Benim sorum iki kat. Revizyon kontrolünde saklanacak veri miktarı ne kadar?

Büyük miktarda test verisini işlemenin daha iyi bir yolu nedir?

Bir yapı zincirindeki büyük dosyaları işleme

Maven veya gradle gibi bağımlılık yönetimi yapan bir oluşturma aracı kullanmayı seviyorum. Dosyalar bir web havuzunda saklanır ve araç, bağımlılıkla karşılaştığında otomatik olarak indirme ve önbelleğe alma ile ilgilenir. Ayrıca, testi çalıştırmak isteyen kişiler için ekstra kurulumu (NAS yapılandırması) da ortadan kaldırır. Ve verileri yenilemeyi oldukça acısız hale getirir (versiyonlanmıştır).

Revizyon kontrolüne girmek için çok büyük olan nedir

Geniş bir gri alan var. Ve bir şeyin bir RCS'ye ait olmadığına karar verirseniz, alternatifleriniz nelerdir? RCS ve ikili bir repo (maven stili) arasındaki seçimlerinizi sınırlarsanız daha kolay bir karardır.

İdeal olarak, yalnızca insanca düzenlenebilir, dağılabilir veya tarihi izlemek istediğiniz RCS öğelerinde istersiniz. Bir yapının veya başka bir tür otomasyonun ürünü olan hiçbir şey kesinlikle oraya ait değildir. Boyut bir kısıtlamadır, ancak ana olanı değildir - dev bir kaynak dosyası (kötü uygulama) kesinlikle kaynak kontrolüne aittir. Küçük bir derlenmiş ikili yapmaz.

Geliştirici rahatlığı için ödün vermeye hazır olun.

NAS çalışmadığında, yavaşsa veya tam test yapamayacağımızdan daha düşük olduğunda.

Açıkçası, bu sadece 5GB'yi NAS'tan yerel sürücünüze kopyalayarak çözülebilir. Ancak bunu manuel olarak yapmaya gerek yoktur.

İkinci neden, birisi bir havuzu ilk kez klonladığında, birim testleri başarısız olur, bu nedenle belirli bir ada sahip şeylerin nasıl bağlanacağını ve test yolu dosyasını oluşturmak için kullanılan sözdizimini bulmaları gerekir.

Tam olarak bunu yapan basit bir kabuk komut dosyası sağlayabilirsiniz - NAS'ı belirli bir adla bağlayın ve verileri henüz orada olmadığında veya NAS'daki veri kümesi yerel veri kümesinden daha yeni olduğunda yerel sürücünüze kopyalayın. Birim testlerinizin başlatma aşamasında komut dosyasının otomatik olarak çalışacağından emin olun.

Tabii ki, bu veri kümelerinden sadece biri değil, kaynak kod deponuzun dışındaki harici dosyalara bir dizi bağımlılık olduğunda, @ptyx tarafından belirtilenler gibi bir araç daha iyi bir çözüm olabilir.

... birisi bir havuzu ilk kez klonladığında, birim testleri başarısız olur, böylece belirli bir ada sahip şeylerin nasıl bağlanacağını ve test yolu dosyasını oluşturmak için kullanılan sözdizimini bulmaları gerekir.

İlk olarak, sadece tutarlı bir terminolojiye sahip olmak için: Bu tür bir test (büyük dış bağımlılıklar, gerçek veriler) genellikle bir birim test olarak değil, bir entegrasyon veya sistem testi olarak kabul edilir .

Pratik bir not: Birim ve entegrasyon testlerini ayrı tutmanın iyi bir uygulama olduğunu düşünüyorum , çünkü farklı güçlü ve zayıf yanları var.

• koddaki iki tür testi ayırın (adlandırma kuralı, ayrı proje, ...)
• iki test paketinden yalnızca birini çalıştırmanın bir yolunu sağlamak
• normal yapılarda sadece birim testlerini yap
• isteğe bağlı olarak ve bir CI (sürekli entegrasyon) sunucusunda entegrasyon testlerini çalıştırın

Bu şekilde, yerel yapılar hızlı ve güvenilirdir (harici bağımlılıklar çok azdır / hiç yoktur) ve entegrasyon testleri etli CI sunucusu tarafından gerçekleştirilir. Bu, tanımladığınız sorunu önler.

Verilerin nasıl saklanacağı hakkında:

İyi bir seçenek, ptyx'in cevabı gibi bir çeşit artefakt yönetimidir. Bir diğeri test verilerini ayrı bir depoya koymak olacaktır . Veriler yine de ana derlemeyle birlikte yayınlanmaz ve ayrı bir repoya sahip olmak, herkesi kaynak kodla birlikte test verilerini almaya zorlar. Başka bir deyişle, artifacdt yönetiminiz olarak ikinci bir repo kullanın :-).