Di mana harus mendorong tes yang gagal?


14

Saya baru saja mengubah pengaturan cabang pada repositori GitHub saya, sehingga cabang [selanjutnya] saya memerlukan pembangunan CI yang lewat melalui permintaan tarik.

Diskusi dilanjutkan dengan sejumlah anggota tim, tentang gagal tes.

Demi konteks ...

Repositori memiliki [induk] cabang yang hanya PR'd ke dalam ketika ada rilis, sehingga [tuan] berisi kode pada rilis terakhir, terlepas dari apakah itu besar, minor, perbaikan terbaru, beta, alpha / membangun pra-rilis.

Cabang [selanjutnya] adalah yang "default", di mana kami bermaksud menyimpan kode "siap-rilis"; secara teknis cabang itu bisa dimasukkan ke [master] kapan saja, dan dirilis.

Garpu individual memiliki cabang dev mereka sendiri, dan kontributor PR ke [selanjutnya].

Ketika saya meninjau PR non-sepele, saya akan menggabungkan cabang dev kontributor ke cabang "review" saya, dan jika saya melihat hal-hal yang dapat saya perbaiki dengan cepat, saya akan melakukan / mendorong perubahan dan pengujian baru (terkadang gagal), dan PR kembali ke cabang dev kontributor; ketika mereka menggabungkan perubahan saya, membuat tes gagal yang baru lulus, dan kemudian mendorong, PR mereka disinkronkan, dan kemudian saya akan menggabungkan PR menjadi [selanjutnya].

Tetapi pertanyaan ini bukan tentang lulus tes, ini tentang yang gagal .


Tes yang gagal mendokumentasikan apa yang perlu diperbaiki.

Bug yang dikenal harus memiliki tes tertulis, sehingga kita tahu apa yang tidak berfungsi.

Secara teknis daftar masalah GitHub (difilter untuk dan / atau label ) juga melakukannya. Apakah praktik yang baik untuk juga memiliki banyak gagal tes untuk bug dokumen?

Gagal membangun pada [selanjutnya] akan berarti bahwa kita tidak siap-lepas ... tapi kemudian "siap-lepas" agak seperti "siap" untuk punya anak - Anda tidak pernah cukup siap untuk ini, dan sesuatu, di suatu tempat (yang sangat penting) pasti akan salah dengan rilis.


Jadi kita hanya mendorong tes kelulusan ke [selanjutnya]. Di mana untuk mendorong tes gagal itu? Maksud saya, di luar proses PR / review?

Sebagai contoh, seorang pengguna melaporkan bug baru dalam daftar masalah, dan saya ingin menulis test suite yang gagal untuknya - sehingga dapat menentukan apa yang perlu dilakukan dan di mana, yang memudahkan kontributor baru untuk mengambil dan akhirnya memperbaiki PR.

Di mana saya harus mendorong tes gagal ini? Atau bahkan ide yang bagus untuk mendorong tes yang gagal di mana saja?


@PhilipKendall poin bagus! kami masih memperbaiki proses kami; Saya tidak suka bagaimana VS mendorong tes "diabaikan" bersama-sama dengan tes "tidak meyakinkan" - jika salah satu tes tingkat rendah gagal, kami tidak ingin separuh tes gagal, jadi kami membuatnya tidak meyakinkan ketika prasyarat tidak terpenuhi ; ini membuat tes melaporkan kegagalan untuk alasan yang tepat, dan "tidak meyakinkan" ketika mereka tidak dapat menguji untuk apa mereka ditulis. Kami tidak memiliki banyak dari mereka (lagi), jadi mengabaikan mereka bisa menjadi pilihan ... tapi kemudian, apakah ini merupakan tes yang gagal jika diabaikan ?
Mathieu Guindon

Mengapa bagian dari proses peninjauan melibatkan Anda menulis kode? Jika Anda melihat bug maka Anda berkomentar di PR dan, opsional, menolak PR.
James

@ James, saya suka menulis kode .. selain karena semakin banyak kontributor bergabung, saya melakukan lebih banyak dan lebih banyak pemeliharaan GitHub dan kerja PR (hubungan masyarakat) daripada pengkodean yang sebenarnya!
Mathieu Guindon

Jawaban:


11

Apa yang akan saya lakukan dalam situasi ini adalah untuk menandai tes gagal sebagai "diabaikan" - dengan cara itu Anda masih memiliki tes sehingga Anda tahu apa yang perlu Anda perbaiki di masa depan, tetapi Anda tidak akan berakhir dengan bangunan yang rusak .

Jika Anda juga menandai setiap tes dengan referensi pelacak masalah untuk memperbaiki masalah, itu memberi Anda cara mudah untuk mengikat semuanya.


4

Pengungkapan penuh: Saya adalah salah satu peserta dalam diskusi.

Cabang utama repositori bukanlah cabang utama. Penggabungan ke master tidak melayani "tujuan aktual" dan cabang itu tidak melakukan hal-hal yang harus dilakukan cabang (yaitu pindah ).
Anda menyalahgunakan cabang ini sebagai Tag untuk rilis terbaru.

Alih-alih menggunakan cabang, gunakan Tag. Saat Anda ingin merilis, Anda membuat langkah-langkah yang diperlukan dalam "Rilis-Cabang", seperti cabang topik. Kemudian Anda menggabungkan itu ke [selanjutnya] dan menaruh Tag di atasnya.

Peran yang selanjutnya dipenuhi adalah peran cabang utama. Hanya kode siap rilis yang ada di sana. Yang lain akan menjadi cabang [berkembang]. Cabang pengembangan berisi pekerjaan yang harus distabilkan . Ini berarti: hapus [master], gunakan kembali [berikutnya] seperti yang sudah Anda lakukan dan buat cabang lain untuk pekerjaan "kurang stabil".

Karena ini lebih merupakan pengecualian daripada aturan bahwa harus ada tes yang gagal, yang mengingatkan bug yang luar biasa, seharusnya tidak terlalu banyak masalah untuk membuat dan menghancurkan cabang yang kurang stabil seperti yang diperlukan


1
Memiliki rilis terbaru di [master] memudahkan untuk melepas rilis terakhir untuk mengeluarkan perbaikan terbaru; maka perbaikan terbaru dapat dipecah ke [berikutnya] dan dari sana ke setiap cabang dev .. atau apakah saya kehilangan sesuatu?
Mathieu Guindon

2
Anda bisa saja git checkout -b HotFix ReleaseTag(itu jika saya ingat cabang membuat sintaks checkout dengan benar). Ini harus membuat cabang HotFix dari ReleaseTag
Vogel612
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.