Test verileri versiyon kontrolünde kontrol edilmeli mi?

40

PDF dosyalarını işleyen bir özellik için bazı test kodları yazıyorum. Testlerin arkasındaki temel fikir, onları özel olarak seçtiğim bazı PDF'lere yöneltmem, onları işlemeleri ve çıktının beklediğim gibi olup olmadığını kontrol etmem.

Sorum şu: bu büyük boyutlu PDF'leri nerede saklamalıyım? Onları kodla birlikte sürüm kontrolünde kontrol etmeli miyim? Ya da başka bir yere mi koyuyorsun? Açıkçası, test kodu PDF'ler olmadan (veya hatta farklı PDF'lerle) işe yaramaz ancak yine de bunları depoya koymak yanlış hissettiriyor.

testing version-control data

— Swiftheart
kaynak

2

Ünite testlerinin

— CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@RobertHarvey Doğru, ancak test verileri çalışabilmesi için gerekliyse, testin bir parçası olarak kabul edilmesi gerektiğini düşünüyorum. Anladığım kadarıyla, bu üç cevabın da aldığı yaklaşım budur.

— 4:14

84

Sürüm kontrol sisteminiz , dağıtım için bir uygulama oluşturmak, derlemek, test etmek ve paketlemek için ihtiyaç duyduğu her şeyi içermelidir (örneğin, MSI, RPM). Ayrıca yapılandırma yapılandırmaları ve diğer betiklerin de sürüm kontrolü altında olması gerektiğini savunuyorum.

Bir projeyi kontrol edebilmeli ve bir derleme, derleme ve test ortamına sahip olmam gerekir.

Test verilerinde kontrol etmek için iki yaklaşım vardır. İlk önce, test verilerinin kendisini kontrol edebilirsiniz (bu durumda PDF'ler). İkinci olarak, test verisi oluşturmak için kullanılabilecek kaynak verileri (varsa) kontrol edebilirsiniz. Bu, test verilerini içeren boş bir veritabanına yüklenen bir SQL betiği veya belki de bir PDF veya başka bir dosyaya derlenmiş bir metin tabanlı dosya olabilir.

Diğerleri her şeyi sürüm kontrolünde kontrol etmekle aynı fikirde olmayabilir , ancak profesyonel deneyimime göre, tam bir ortamın sıfırdan yeniden oluşturulabilmesinin sağlanması açısından kritik öneme sahip olduğunu gördüm.

20

Evet. Kesinlikle evet. 2014'te, ikili dosyaları sorunsuz bir şekilde işlemeyen revizyon kontrolünü kullanmak için hiçbir gerekçe yoktur.

— Kilian Foth

4

Aynı fikirdeyim ama kesinlikle önemsiz eşyaları da kontrol etmekte olduğunuz durumdan kaçınmak istiyorsunuz. Örneğin, test verileri, testler tarafından oluşturulan tüm pdf dosyalarını içeren bir "çıktı" klasörü içeriyorsa, bunu depoya dahil etmek istemeyeceksiniz. Ancak, testlerin kendilerinin deponun ve çalışması için gereken paketlerin bir parçası olması gerektiğine katılıyorum.

— Kenneth Garza

1

@KennethGarza Gerçekten zor değil. Genel bir kural olarak, tüm veriler (kaynak kod, test kaynak kodu, test verileri, medya, [gerçek] belgeler, üçüncü taraf kütüphaneleri, derleme komut dosyaları, araç kodları, dönüştürme komut dosyaları vb.) Dahil edilmelidir. Orijinal verilerden makul bir zamanda üretilebilecek olmamalıdır. Ayrıca, bunlar test çıktıları göz önüne alındığında, muhtemelen yalnızca testleri kendiniz yürüttükten sonra mantıklı olurlar ; aksi takdirde, programınızı test etmezsiniz, VCS yazılımının dosyalarınızın bütünlüğünü koruma yeteneğini test edersiniz :)

— Thomas

1

@ MarnenLaibow-Koser: implante edilmiş kalp pili uçlarındaki elektriksel arızayı tespit etmek için üzerinde çalıştığım bir projede 40GB'ın üzerinde bir test paketi vardı. Bununla başa çıkmanın iğrenç olmadığı bir VCS yoktur. İki repo sahibi olmak, kendi başına bir güçlüktür, ancak bazen daha iyi bir seçim olabilir.

— whatsisname,

1

@ MarnenLaibow-Koser aldın. Entegrasyon testleri ayrı depodadır ve eğer kullanıcı yerel olarak çalıştırmak isterse, bağımlılık yönetimi onun için zip dosyasını getirir ve sıkıştırmasını açar. Genellikle Sürekli Entegrasyon sunucusu / çiftliği, entegrasyon testi yapmakla görevlidir ve entegrasyon testleri geçinceye kadar özellik dallarının birleştirilmesini önler.

— user482745 22:18

15

Testler, hazırladığınız kurulum dosyaları olmadan işe yaramazsa, dosyaları VCS'nize test koduyla birlikte eklemek mantıklı olacaktır.

Testte kullanılan dosyalar kod değildir, ancak kodun dayandığı bir bağımlılık olarak görebilirsiniz. Yani her şeyi bir arada tutmanın yararı var.

Bir karşılaştırma noktası olarak, bazı VCS'ler büyük ikili dosyaları iyi işlemez ve diğerleri bir VCS'deki herhangi bir ikili dosyayı dahil etmeye güçlü şekilde karşıdır. Bu davalardan herhangi biri sizin için geçerliyse, test dosyalarını kolayca erişilen iyi bilinen bir yerde saklamak da mantıklı olacaktır.

Test koduna " foo.pdftüm testleri yapmak için güveniyor" yazan bir yorumda bulunmayı da düşünebilirim .

Testlerin test verilerini kontrol etmesinde yanlış bir şey görmüyorum, eğer bulunmazsa (örneğin bir URL’den) ve eğer işe yaramadıysa başarısız olur. Ağa güvenmek kötü bir fikir çünkü testleri daha yavaş ve daha kırılgan hale getiriyor; ancak, denemekten daha az kırılgandır ve doğru verileri otomatik olarak almak (ve yerel olarak önbelleğe almak), belgeleri / yorumları manuel olarak okumaktan, almak ve yerine koymaktan daha hızlıdır.

— Warbo

7

Eğer statik veri ise, evet versiyon kontrolüne koyun. Bu dosyalar teslim edildikten sonra gerçekten değişmeyecek; işlevsellik artık gerekli değilse ya da kaldırılacaklar ya da yeni test dosyaları eklenecek. Her iki durumda da, yer kaplayan fakir ikili farklar konusunda endişelenmenize gerek yok.

Eğer konum üreten örneğin test verilerini. rastgele, o zaman bir test başarısız olduğunda otomatik olarak kaydetmeniz gerekir, ancak aksi takdirde atın. Bu şekilde kaydedilen herhangi bir veri düzenli regresyon testlerine dönüştürülmelidir, böylece bu kenar davaları kesinlikle çekiliş şansına güvenmek yerine gelecekte test edilir.

— Warbo
kaynak

2

Rastgele bir test verisi oluşturuyorsanız, gerçekten çıkmalı ve yeniden üretilebilir otomatik testler yazma hakkında bir kitap satın almalısınız.

— Dawood, Monica

5

@DavidWallace Yani, fuzz testi, özellik kontrolü ve istatistiksel yazılım testi gibi tüm alanların sadece yanlış değil, zararlı olduğunu mu söylüyorsunuz?

— Warbo

5

@DavidWallace random! = Yeniden üretilemez.

— congusbongus

5

@DavidWallace daha sonra ne istersen onu çağırabilirsin. Rastgele test verileri, girişleri kaydedin, gerekirse geri dönüştürün, yeniden üretilebilir. Bir acı dünyasına yol açmaz.

— congusbongus

2

@DavidWallace "hangi test durumlarının gerçekten gerekli olduğu hakkında düşünmeyi bırakmak yerine" "rastgele test yok" anlamına gelmez, " sadece rastgele test değil" anlamına gelir . "Hatayı bulan verileri çoğaltamazsınız" derken, yorum yaptığınız cevabı okudunuz mu? ;)

— Warbo

0

Bu verileri kesinlikle testlerinize ve ana uygulama kodunuza ekleyin. Gerçekten iyi organize edilmiş bir test takımına sahip olmanıza yardımcı olur - pdf çıkarımını test ediyorsanız (ve bu kodu güzel bir şekilde kapsüllenmişse), uygulama kodunun yolunu temel alarak test verilerinize bir yol oluşturabilmelisiniz. - bu her zaman benim için çalıştı.

Git ile herhangi bir geçici çıkışın önüne geçmek için bir .gitignore kurabilir ya da test günlüğünün reponuzu kirletmesini önleyebilirsiniz.

— NickJHoran
kaynak