Kode uji pengiriman. Kenapa tidak?

Saya ingin mengirimkan kode uji bersama produk. Secara khusus, berikan opsi sehingga siapa pun yang memiliki salinan program kami dapat menekan tombol "swa-uji" atau lulus swa-uji pada baris perintah dan jalankan melalui rangkaian lengkap unit | tes integrasi.

Saya sebagian besar ingin melakukan ini untuk membantu masalah debug ditemukan di lapangan, jadi ketika laporan bug masuk dari pengguna akhir ada kemungkinan itu didukung oleh "dan juga, tiga tes ini gagal pada mesin saya". Saya ingin penguji manual untuk dapat menjalankan unit | tes integrasi juga.

Namun, pengujian tim percaya bahwa kode pengujian bukan kode produksi dan karenanya tidak boleh dikirimkan. Saya tidak benar-benar mendapatkan argumen ini, karena sebagian besar proyek open source mengirimkan test suite. Tampaknya tidak biasa dalam perangkat lunak tertutup.

Saya ingin mendukung bukti atau anekdot untuk kedua sisi argumen. Saya telah mengambil tebakan terbaik saya di mana situs pertukaran tumpukan akan paling tepat, tetapi tolong beri tahu saya jika ini tidak pada tempatnya.

Terkadang kode uji berisi potongan kode dari pihak ketiga, baik eksternal maupun internal perusahaan Anda. Ini terjadi ketika pengguna mengajukan bug; tes Anda (seperti tes regresi) kemudian memasukkan kode yang disediakan oleh mereka untuk mereproduksi. Seringkali, lisensi snipet kode tersebut untuk mereproduksi bug tidak jelas. Jadi, Anda harus mewaspadai masalah kekayaan intelektual. Anda tidak ingin mengirimkan kode uji yang secara tidak sengaja mengungkapkan beberapa rahasia dagang atau kekayaan intelektual dari departemen lain di perusahaan Anda, atau dari mitra eksternal Anda.

Pada catatan lain, kode uji jarang dipegang oleh standar kode produksi: tinjauan kode tidak harus dilakukan; standar pengkodean tidak ditegakkan, dll. Ini sangat disayangkan, namun lumrah, dan seharusnya tidak mencerminkan tim tes dengan buruk jika mereka tidak memiliki tujuan tersebut pada saat tes ini dikembangkan.

Di sisi lain, banyak tes yang benar-benar buruk, dan bahkan tidak menguji apa yang menurut beberapa orang sedang diuji. Itu masalah yang berbeda ...

Pada akhirnya, karena semua faktor ini, Anda mungkin ingin mengklasifikasikan tes Anda sebagai yang dapat dikirim sebagai sumber terbuka , dan yang tidak bisa. (Anda mungkin ingin menulis beberapa tes khusus dengan mempertimbangkannya, secara perlahan memigrasi yang lain ke set itu.)

Tes pengiriman? Iya. Tes Unit Pengiriman? Tidak.

Seperti yang Anda katakan di komentar, masalah yang mungkin Anda hadapi saat menjalankan produk pada komputer klien akan mencakup masalah seperti menghubungkan dengan dll yang salah, umumnya ini bukan sesuatu yang akan ditangkap unit test (yang tidak diragukan lagi akan mengejek dll keluar untuk menguji kode).

Sekarang, mengirim suite uji integrasi, yang memanggil UI yang memanggil logika yang memanggil dll ... yang akan bekerja lebih baik. Tes integrasi dapat menunjukkan aspek lain dari instalasi yang gagal yang tidak akan ditunjukkan oleh pengujian unit. (mis. produk saya saat ini membutuhkan instalasi codec k-lite, yang kami tidak boleh bundel karena lisensi. Uji unit dapat menunjukkan kode kami berfungsi dengan baik, tetapi masih tidak berfungsi untuk kepuasan pelanggan. Demikian pula, konfigurasi codec kami mungkin tidak bekerja dengan benar, unit test juga tidak akan menunjukkannya).

Jadi, kirimkan beberapa tes integrasi Anda, yang akan persis seperti yang Anda inginkan untuk produk yang terinstal dan terintegrasi.

Saya bisa memahami masalah ini dengan kuat di area di mana Anda menutupi setiap inci perangkat keras, seperti mesin game AAA generasi berikutnya yang multithreaded yang menggunakan setiap inti CPU tunggal, intrinsik SIMD, GPU, GPGPU, dll. Sambil memberikan cross-platform produk.

Dalam kasus-kasus itu, mimpi terburuk Anda akan sering menjadi kasus-kasus di mana pengujian Anda (unit dan integrasi) akan lolos untuk 5.000 mesin / platform yang berbeda yang diuji, tetapi gagal untuk yang ke 5.001 karena bug driver untuk model GPU yang tidak jelas Hanya berpikir tentang ini memberi saya menggigil - Anda tidak dapat menguji atau meramalkan ini sebelumnya.

Terutama jika Anda menulis GPU shader, Anda dapat memainkan lotre terbalik di mana separuh kode yang Anda tulis akan memicu perilaku tidak terdefinisi, karena ada beberapa jaminan standar portabel yang diberlakukan oleh semua model / driver GPU yang terlibat. Meskipun semakin tidak seperti bermain kapal penyapu ranjau akhir-akhir ini, ini seharusnya memberi orang ide: http://theorangeduck.com/page/writing-portable-opengl . Mencoba ini di akhir 90-an dan awal 2000-an benar-benar mengerikan, dan itu adalah kapal penyapu ranjau sepanjang jalan.

Untuk jenis-jenis kasus, Anda sering perlu tim dari 10.000 penguji dengan benar-benar luas berbagai perangkat keras dan sistem operasi untuk benar-benar memantapkan produk dan merasa yakin tentang hal itu sebelum rilis stabil. Tidak semua perusahaan mampu memiliki basis pengujian yang luas, dan tidak semua memiliki disiplin untuk melakukannya dengan benar (semua masalah yang dapat dilihat secara luas harus diperbaiki sebelum memiliki begitu banyak penguji di beberapa tahap pra-alfa / alfa internal atau yang lain). membanjirnya laporan yang berlebihan bisa membuat para pengembang panik dan panik).

Apa yang saya rekomendasikan dalam kasus ini adalah apa yang disarankan orang lain, fokus pada serangkaian tes integrasi yang didistribusikan. Anda dapat menggabungkannya dengan penginstal, yang mengharuskan pengguna untuk lulus pemeriksaan diagnostik dasar dengan perhatian cermat untuk memberikan perincian mengapa instalasi gagal yang dapat mereka sampaikan kepada Anda, para pengembang.

Hal lain (jika Anda dapat meyakinkan bos) adalah memiliki berbagai perangkat keras yang tersedia untuk melakukan integrasi yang berdekatan. Semakin banyak variasi hardware / OS combo, semakin meriah. Anda bahkan menginginkan berbagai perangkat keras sampah yang memodelkan persyaratan perangkat keras minimum untuk server CI Anda: Anda tidak pernah tahu.

Tapi ada satu hal lagi yang saya sarankan:

Penebangan

Jika Anda berurusan dengan sesuatu seperti skenario yang saya jelaskan di atas, maka sering kali Anda tidak mungkin menguji hal-hal ini yang cenderung paling bermasalah (para gotcha terburuk yang muncul pada waktu terburuk dan tidak mungkin muncul bahkan di sebagian besar test suite lengkap karena masalah ini terbatas pada kombinasi hardware / OS yang sangat spesifik).

Namun sebagian besar dari masalah-masalah seperti ketidakcocokan perangkat keras yang tidak jelas atau gangguan driver langsung atau menghubungkan dengan dylib yang salah (saya tidak pernah benar-benar menghadapi masalah ini) tidak akan membuat Anda jauh melewati memulai perangkat lunak. Biasanya akan crash dan terbakar segera, berbicara dengan kasar.

Saya sarankan, demi kewarasan, untuk merangkul hal yang tak terhindarkan. Anda tidak dapat melakukan apa pun tentang hal-hal ini yang tidak dapat Anda uji secara komprehensif. Jangan mencoba untuk mencegah badai (tidak mungkin), tetapi naiklah ke jendela itu.

Biasanya di sini, hal terbaik yang bisa kita lakukan adalah mencari tahu masalahnya sesegera mungkin, di mana itu terjadi sedetail mungkin (untuk mempersempit daftar tersangka kami), dan memiliki masalah diperbaiki ASAP setelah dilaporkan.

Dalam hal ini, penebangan bisa menjadi penyelamat. Untuk jenis bidang ini, Anda dapat membuat log teknis spam ini yang tidak akan pernah dibaca oleh siapa pun. Seringkali yang relevan hanya baris paling terakhir yang dicatat dalam log sebelum pengguna menghadapi kerusakan karena kesalahan driver, misalnya Anda dapat menulis proses eksternal atau kait yang memantau crash dan kemudian menunjukkan baris terakhir dari log yang dapat disalin pengguna dan tempelkan kepada Anda, misalnya sebagai tambahan untuk tempat pembuangan kerusakan.

Karena ini sering membutuhkan informasi terperinci dan banyak area yang paling rentan dalam kode untuk masalah perangkat keras / platform / driver ini sangat penting untuk kinerja, ada masalah canggung di mana penebangan dapat terjadi pada tingkat yang sering sehingga benar-benar akan memperlambat turun perangkat lunak.

Trik yang berguna dalam kasus ini adalah mengandalkan asumsi bahwa sesuatu yang dieksekusi sekali akan berhasil dijalankan untuk kedua kalinya, ketiga kalinya, dll. Ini bukan asumsi yang paling masuk akal, tetapi sering kali "cukup baik" (dan jauh lebih baik daripada tidak sama sekali) . Dengan itu, Anda dapat menggunakan sedikit kondisi eksternal untuk melacak kapan sesuatu telah dicatat dan melewati upaya berikutnya untuk mencatat kasus-kasus yang sangat terperinci di mana kode akan dipanggil berulang kali dalam satu lingkaran.

Bagaimanapun, saya harap ini membantu. Saya pernah mengalami godaan semacam ini di masa lalu dan memiliki sedikit paranoia seputar pengodean GPU (GPGPU dan shaders) sebagai hasil dari beberapa pengalaman masa lalu di antara saya dan tim saya (kadang-kadang hanya melihat anggota tim lain berurusan dengan hal ini benar-benar terlambat dan pasca rilis membuat saya merinding, seperti beberapa kesalahan ATI pada model Radeon tertentu yang akan crash pada rendering baris antialiased, kemudian dilaporkan dan ditandai sebagai masalah yang diketahui dengan hanya solusi penyelesaian yang tersedia).

Penebangan adalah hal yang menyelamatkan puntung kami di sana, membiarkan kami sering melihat masalah pada mesin prototipe kabur ke-10.001 dengan GPU onboard yang belum pernah kami dengar, dengan baris kode terakhir segera membiarkan kami melihat persis di mana kegagalan turun ke 2. atau 3 baris kode sebagai tersangka, mis. Jika berada di dalam shader yang rumit, kami semacam SOL karena kami tidak dapat melakukan logging di dalam shader GPU, tetapi setidaknya kami dapat menggunakan logging untuk melihat shader mana yang memiliki masalah saat itu juga. untuk memulai penyelidikan.