Haruskah unit test disimpan di repositori?

50

Saya seorang programmer yang sedang berkembang yang akhirnya mempraktikkan pengujian unit untuk perpustakaan yang saya simpan di GitHub.

Terpikir oleh saya bahwa saya mungkin memasukkan suite tes dalam repo, tetapi ketika saya melihat-lihat proyek lain, dimasukkannya tes tampaknya hit-or-miss.

Apakah ini dianggap bentuk yang buruk? Apakah gagasan bahwa pengguna hanya tertarik pada kode kerja dan bahwa mereka akan menguji dalam kerangka kerja mereka sendiri?

version-control unit-testing

— parisminton
sumber

13

Kenapa tidak? Tes harus datang bersama dengan proyek atau mereka hampir tidak berguna.

61

Fakta bahwa beberapa proyek tidak memasukkan tes unit dalam repositori mereka lebih mungkin karena tidak adanya tes ini di tempat pertama.

— prasopes

4

Mereka dibangun secara terpisah, tetapi jika tidak, tes-u digabungkan dengan kode. Untuk memastikan konsistensi harus ada semacam manajemen ketergantungan. Baik itu menempatkan mereka ke dalam repositori, subrepositori atau mempertahankan "tautan" yang dikontrol versi yang sama untuk menguji repositori, dll.

— MaR

2

@ stoupa benar-benar tepat: akan sangat menyenangkan untuk menganggap yang terbaik, bahwa ada cache tes yang bagus tersembunyi di suatu tempat, tetapi di dunia nyata, programmer malas.

— Cascabel

2

Catatan, bahwa saya akan mempertimbangkan itu ide yang baik untuk menonaktifkan kompilasi kelas tes di skrip build Anda.

— user606723

119

Anda pasti harus memasukkan tes Anda ke dalam repositori. Tes menurut saya bagian dari kode dan dapat sangat membantu orang lain untuk memahaminya (jika ditulis dengan baik). Selain itu, mereka dapat membantu orang lain ketika mengubah atau berkontribusi pada basis kode Anda. Tes yang baik dapat memberi Anda kepercayaan diri bahwa perubahan Anda tidak merusak apa pun secara tidak sengaja.

Kode uji harus dipisahkan dengan baik dari kode produksi. Maven misalnya mencapai ini dengan meletakkan kode produksi dan uji ke folder yang berbeda. Pertanyaan "apakah ini bagian dari produksi atau kode uji" seharusnya tidak pernah muncul.

Saya pribadi tidak menulis tes unit untuk perpustakaan yang digunakan dalam kode saya sendiri. Saya berharap mereka berfungsi (setidaknya ketika saya menggunakan versi rilis, meskipun bug jelas dapat muncul). Itu mendapat beberapa cakupan tes dalam tes integrasi, tapi itu tidak cukup.

— ftr
sumber

1

Sebagai contoh lain, lihat folder pengujian ipython . Jika seseorang memeriksanya, di mana pun mereka meletakkannya, tautan relatif untuk pengujian masih benar. Itu membuatnya sepele untuk mengujinya, yang penting untuk menentukan apakah mesin dev baru Anda dikonfigurasi dengan benar.

— Spencer Rathbun

Tes tidak hanya bagian dari kode, tetapi juga bagian dari dokumentasi, dan seringkali bagian dari spesifikasi. Tes (yang berjalan dan lulus) adalah "dokumentasi hidup".

— Michael Easter

54

Jika Anda tidak memasukkan tes unit dalam kode sumber check-in, maka:

bagaimana seseorang yang mengunduh dan membuat salinan kode itu sendiri akan memverifikasi bahwa itu berfungsi seperti yang dimaksudkan? Bug kompiler dan pustaka jarang terjadi, dan kesalahan data (terutama yang tidak membuat kode sumber tidak mungkin untuk dikompilasi) bahkan lebih jarang, tetapi mereka pasti dapat memotong, terutama ketika Anda tidak dapat menentukan lingkungan build sejauh suatu majikan dapat menentukan alat mana yang digunakan.
bagaimana Anda akan mendapatkan tes kembali jika terjadi sesuatu pada salinan kode sumber lokal Anda?
bagaimana pengembang baru akan memverifikasi bahwa perubahan mereka tidak merusak apa pun di basis kode yang ada?

Intinya, saya akan mempertimbangkan untuk tidak memasukkan tes unit yang ditulis dalam repositori kode sumber resmi hal yang sangat buruk.

— sebuah CVn
sumber

7

Tentu saja Anda harus memasukkan unit test ke dalam repositori, karena beberapa alasan:

mudah untuk kembali ke versi sebelumnya
orang lain yang mengerjakan proyek juga mendapatkan akses ke unit test
beberapa orang menganggap unit test sebagai bagian dari dokumentasi (TDD dan BDD)

— BЈовић
sumber

6

Jika ada kesempatan untuk menjalankannya di komputer lain, pasti termasuk mereka. Mereka harus dibangun secara terpisah, sehingga pengguna tidak harus, dan mereka mungkin memiliki dependensi tambahan, tetapi mereka harus dimasukkan dengan pasti.

Saya sangat curiga sebagian besar proyek yang tidak termasuk tes dalam repositori tidak punya.

Mungkin ada alasan untuk melakukan tes sebagai modul terpisah, sehingga Anda dapat dengan mudah menjalankan tes baru terhadap kode lama. Ini akan berguna untuk pustaka API-stable atau pengujian kotak hitam melalui command-line; kegunaan untuk bahasa yang dikompilasi di mana tes baru mungkin tidak akan dikompilasi dengan kode yang lebih lama terbatas.

— Jan Hudec
sumber

5

Benar. Poin bonus tambahan di sini adalah kemampuan untuk melacak bahwa versi X dari file sumber berjalan dengan versi Y dari tes. Dengan kata lain, Anda harus dapat kembali ke versi sebelumnya dan menarik tes yang sesuai yang dirancang untuk versi itu (jika terjadi perubahan API atau semacamnya).

— segera
sumber

3

Saya baru saja selesai membaca "Pengembangan Aplikasi Brownfield dalam. Net" , dan ini memberikan beberapa saran yang sangat baik tentang struktur aplikasi, termasuk kontrol sumber dan di mana / bagaimana / mengapa menyertakan tes unit (terutama di bidang Integrasi Berkelanjutan) . Jika Anda seorang pengembang .Net, saya akan merekomendasikannya.

— seanfitzg
sumber