Haruskah data uji diperiksa ke dalam kontrol versi?

40

Saya sedang menulis beberapa kode uji untuk fitur yang memproses file PDF. Ide dasar di balik tes ini adalah saya mengarahkan mereka ke beberapa PDF yang saya pilih secara khusus, mereka memprosesnya dan saya memeriksa apakah hasilnya sesuai dengan yang saya harapkan.

Pertanyaan saya adalah: di mana saya harus menyimpan file PDF besar ini? Haruskah saya memeriksanya ke dalam kontrol versi bersama dengan kode? Atau menempatkannya di tempat lain? Jelas, kode uji tidak berguna tanpa PDF (atau bahkan dengan PDF berbeda) tetapi tetap saja, memasukkannya ke dalam repositori kami terasa salah.

testing version-control data

— Sapu tangan
sumber

2

kemungkinan duplikat Haruskah unit test disimpan dalam repositori?

— CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@RobertHarvey Benar, tetapi jika data uji diperlukan agar tes berfungsi, saya merasa itu harus dianggap sebagai bagian dari tes. Itu juga pendekatan yang diambil oleh ketiga jawaban sejauh ini, seperti yang saya pahami.

— CVn

84

Sistem kontrol versi Anda harus berisi semua yang dibutuhkan untuk membangun, mengkompilasi, menguji , dan mengemas aplikasi untuk distribusi (mis. MSI, RPM). Saya juga berpendapat konfigurasi build dan skrip lain juga harus dalam kontrol versi.

Saya harus dapat memeriksa proyek dan memiliki lingkungan kompilasi, pembangunan, dan pengujian yang lengkap.

Ada dua pendekatan untuk memeriksa data uji. Pertama, Anda dapat memeriksa data tes itu sendiri (PDF dalam hal ini). Kedua, Anda dapat memeriksa data sumber yang dapat digunakan untuk menghasilkan data uji (jika berlaku). Ini bisa berupa skrip SQL yang dimuat ke basis data kosong yang berisi data uji, atau mungkin file berbasis teks yang dapat dikompilasi ke dalam PDF atau file lain.

Orang lain mungkin tidak setuju dengan memeriksa semuanya ke dalam kontrol versi, tetapi saya telah menemukan dalam pengalaman profesional saya sangat penting untuk memastikan lingkungan yang lengkap dapat dibangun kembali dari awal.

20

Iya nih. Pastinya ya. Ini tahun 2014, tidak ada alasan apa pun untuk menggunakan kontrol revisi yang tidak menangani file biner dengan mulus.

— Kilian Foth

4

Saya setuju, tetapi Anda pasti ingin menghindari situasi di mana Anda memeriksa barang-barang sampah juga. Misalnya, jika data uji menyertakan folder "output" yang berisi semua file pdf yang dihasilkan oleh tes, maka Anda ingin tidak memasukkannya ke dalam repositori. Tapi saya setuju tes itu sendiri harus menjadi bagian dari repo serta paket apa pun yang diperlukan untuk menjalankannya.

— Kenneth Garza

1

@KennethGarza Tidak sulit, sungguh. Sebagai aturan praktis, konten asli apa pun (kode sumber, kode sumber pengujian, data uji, media, dokumentasi [nyata], perpustakaan pihak ketiga, skrip bangun, skrip tooling, skrip konversi, dll.) Harus dimasukkan, sementara semua data yang dapat dihasilkan dalam waktu yang wajar dari data asli seharusnya tidak. Selain itu, mengingat itu adalah hasil pengujian, mereka mungkin hanya masuk akal setelah menjalankan tes sendiri, jika tidak Anda tidak menguji program Anda, Anda menguji kemampuan perangkat lunak VCS untuk menjaga integritas file Anda :)

— Thomas

1

@ MarnenLaibow-Koser: proyek yang saya kerjakan untuk mendeteksi kegagalan listrik pada lead pacemaker implan memiliki test suite lebih dari 40GB. Tidak ada VCS yang ada di mana berurusan dengan itu tidak menjengkelkan. Memiliki dua repo adalah masalah administrasi sendiri, tetapi kadang-kadang bisa menjadi pilihan yang lebih baik.

— whatsisname

1

@ MarnenLaibow-Koser Anda mengerti. Tes integrasi dalam repo terpisah dan jika pengguna ingin menjalankannya secara lokal, manajemen dependensi akan mengambil file zip untuknya dan mendekompresnya. Biasanya Continuous Integration server / farm ditugaskan untuk melakukan tes integrasi dan akan mencegah penggabungan cabang fitur hingga tes integrasi lulus.

— user482745

15

Jika tes tidak berguna tanpa file setup yang telah Anda siapkan, maka masuk akal untuk memasukkan file dalam VCS Anda bersama dengan kode tes.

Meskipun file yang digunakan dalam tes ini bukan kode, Anda dapat melihatnya sebagai ketergantungan yang bergantung pada kode. Jadi ada manfaat dalam menyatukan semuanya.

Sebagai tandingan, beberapa VCS tidak menangani file biner besar dengan baik, dan yang lain memiliki oposisi yang kuat untuk memasukkan segala jenis file biner dalam VCS. Jika salah satu dari kasus-kasus itu berlaku untuk Anda, maka menyimpan file uji di lokasi yang terkenal yang mudah diakses juga masuk akal.

Saya juga akan mempertimbangkan untuk memberikan komentar dalam kode tes yang mengatakan "bergantung pada foo.pdfuntuk menjalankan semua tes."

Saya tidak melihat ada yang salah dengan tes memeriksa data tes, jika tidak ditemukan maka mencoba untuk mendapatkannya (mis. Dari URL) dan gagal jika tidak berfungsi. Mengandalkan jaringan adalah ide yang buruk karena membuat tes lebih lambat dan lebih rapuh; tetapi mencoba kurang rapuh daripada tidak, dan secara otomatis mendapatkan (dan caching secara lokal) data yang tepat lebih cepat daripada membaca dokumen / komentar secara manual, membuatnya dan meletakkannya di tempat.

— Warbo

7

Jika itu data statis, maka ya letakkan di kontrol versi. File-file itu tidak akan benar-benar berubah begitu mereka masuk; mereka akan dihapus jika fungsi itu tidak lagi diperlukan, atau file uji baru akan ditambahkan bersama. Either way, Anda tidak perlu khawatir tentang diff biner miskin mengambil ruang.

Jika Anda menghasilkan data uji, mis. secara acak, maka Anda harus menyimpannya secara otomatis ketika tes gagal, tetapi buanglah sebaliknya. Setiap data yang disimpan dengan cara ini harus diubah menjadi tes regresi reguler, sehingga kasus tepi tersebut pasti diuji di masa depan daripada mengandalkan keberuntungan undian.

— Warbo
sumber

2

Jika Anda menghasilkan data uji secara acak, maka Anda harus benar-benar keluar dan membeli buku tentang penulisan tes otomatis yang dapat direproduksi.

— Dawood mengatakan mengembalikan Monica

5

@ Davidvidallace Jadi Anda mengatakan seluruh bidang seperti pengujian fuzz, pemeriksaan properti dan pengujian perangkat lunak statistik tidak hanya salah, tetapi juga berbahaya?

— Warbo

5

@ Davidvidallall acak! = Tidak dapat diproduksi ulang.

— congusbongus

5

@ Davidvidallall Anda dapat menyebutnya apa pun yang Anda inginkan. Data uji acak, rekam input, daur ulang jika perlu, ergo dapat direproduksi. Tidak mengarah ke dunia yang terluka.

— congusbongus

2

@ Davidvidallallace "alih-alih berhenti untuk memikirkan kasus uji mana yang benar-benar dibutuhkan" tidak berarti "tidak ada pengujian acak", itu berarti "tidak hanya pengujian acak". Adapun "Anda tidak dapat mereproduksi data yang menemukan bug", apakah Anda benar-benar membaca jawaban yang Anda komentari? ;)

— Warbo

0

Sertakan data itu dengan tes Anda dan kode aplikasi utama Anda. Ini membantu untuk memiliki test suite yang terorganisir dengan sangat baik - jadi jika Anda menguji ekstraksi pdf (dan Anda memiliki kode yang dienkapsulasi dengan baik) maka Anda harus dapat membangun jalur ke data pengujian Anda, berdasarkan jalur ke kode aplikasi - Itu selalu berhasil untukku.

Dengan git, Anda dapat mengatur .gitignore untuk mencegah keluaran sementara atau pengujian logging dari mencemari repo Anda.

— NickJHoran
sumber