Di mana saya harus menyimpan data uji?

Saya memiliki tes unit yang lebih kecil yang menggunakan cuplikan kecil dari kumpulan data nyata. Saya juga ingin menguji program saya terhadap set data lengkap karena banyak alasan. Satu-satunya masalah adalah bahwa dataset nyata tunggal sekitar ~ 5GB. Saya belum menemukan angka sulit untuk apa yang bisa disimpan repositori Git tetapi sepertinya terlalu banyak.

Menurut posting Programmer ini saya harus menyimpan semua data saya yang diperlukan untuk menguji proyek di repositori.

Solusi yang tim saya telah adopsi adalah bahwa proyek memiliki file yang berisi jalur ke sistem file terlampir jaringan yang menyimpan data pengujian kami. File ini diabaikan Git.

Saya merasa ini adalah solusi yang tidak sempurna karena dua alasan. Ketika NAS tidak berfungsi, lambat, atau turun daripada kita tidak bisa menjalankan tes penuh. Alasan kedua adalah bahwa ketika seseorang pertama kali mengkloning repositori, unit test gagal sehingga mereka harus mencari cara untuk me-mount sesuatu dengan nama tertentu dan sintaks yang digunakan untuk membangun file path pengujian.

Jadi pertanyaan saya ada dua. Berapa banyak data, terlalu banyak data untuk disimpan dalam kontrol revisi?

Apa cara yang lebih baik untuk menangani sejumlah besar data uji?

Cara menangani file besar dalam rantai build

Saya suka menggunakan alat membangun yang melakukan manajemen ketergantungan - seperti pakar atau gradle. File-file tersebut disimpan dalam repositori web, dan alat ini menangani pengunduhan dan penyimpanan secara otomatis ketika menemui ketergantungan. Ini juga menghilangkan pengaturan tambahan (konfigurasi NAS) untuk orang yang ingin menjalankan tes. Dan itu membuat penyegaran data cukup menyakitkan (ini versi).

Apa yang terlalu besar untuk dimasukkan ke dalam kontrol revisi

Ada area abu-abu besar. Dan jika Anda memutuskan sesuatu tidak termasuk dalam RCS, apa alternatif Anda? Ini adalah keputusan yang lebih mudah jika Anda membatasi pilihan Anda antara RCS dan repo biner (gaya pakar).

Idealnya, Anda hanya ingin hal-hal RCS yang dapat diedit secara manusiawi, difabel, atau di mana Anda ingin melacak sejarah. Apa pun yang merupakan produk dari bangunan atau jenis otomatisasi lainnya pasti bukan milik di sana. Ukuran adalah kendala, tetapi bukan yang utama - file sumber raksasa (praktik buruk) pasti termasuk dalam kontrol sumber. Biner terkompilasi kecil tidak.

Bersiaplah untuk berkompromi untuk kenyamanan pengembang.

Ketika NAS tidak berfungsi, lambat, atau turun daripada kita tidak bisa menjalankan tes penuh.

Jelas, ini hanya dapat diselesaikan dengan menyalin 5GB dari NAS ke drive lokal Anda. Tetapi tidak perlu melakukan ini secara manual.

Alasan kedua adalah bahwa ketika seseorang pertama kali mengkloning repositori, unit test gagal sehingga mereka harus mencari cara untuk me-mount sesuatu dengan nama tertentu dan sintaks yang digunakan untuk membangun file path pengujian.

Anda bisa memberikan skrip shell sederhana yang melakukan hal ini - pasang NAS dengan nama tertentu, dan salin data ke drive lokal Anda ketika belum ada di sana, atau ketika dataset di NAS lebih baru daripada dataset lokal. Pastikan skrip akan berjalan secara otomatis selama tahap inisialisasi pengujian unit Anda.

Tentu saja, ketika tidak hanya ada satu set data, tetapi sejumlah besar dependensi ke file eksternal di luar repositori kode sumber Anda, maka alat seperti yang disebutkan oleh @ptyx mungkin merupakan solusi yang lebih baik.

... ketika seseorang pertama mengkloning repositori, unit test gagal sehingga mereka harus mencari cara untuk me-mount sesuatu dengan nama tertentu dan sintaks yang digunakan untuk membangun file path pengujian.

Pertama, hanya untuk memiliki terminologi yang konsisten: Tes semacam ini (dependensi eksternal besar, data nyata) biasanya tidak dianggap sebagai unit test, melainkan tes integrasi atau sistem .

Pada catatan praktis: Saya merasa praktik yang baik untuk menjaga unit dan integrasi tes terpisah , karena mereka memiliki strenghts dan kelemahan yang berbeda.

• pisahkan kedua jenis tes dalam kode (konvensi penamaan, proyek terpisah, ...)
• menyediakan cara untuk menjalankan hanya satu dari dua rangkaian pengujian
• jalankan hanya unit test selama build normal
• menjalankan tes integrasi sesuai permintaan, dan pada server CI (integrasi berkelanjutan)

Dengan begitu, build lokal cepat dan andal (sedikit / tidak ada dependensi eksternal), dan tes integrasi ditangani oleh server CI yang gemuk. Ini menghindari masalah yang Anda gambarkan.

Bagaimana cara menyimpan data:

Salah satu opsi yang baik adalah beberapa jenis manajemen artifak seperti dijelaskan oleh ptyx. Lain akan menempatkan data uji ke dalam repositori terpisah . Data tidak dirilis bersamaan dengan build utama, dan memiliki repo yang terpisah mencegah semua orang untuk mengambil data uji bersama dengan kode sumber. Dengan kata lain, gunakan repo kedua sebagai manajemen artifacdt Anda :-).