Bagaimana saya memeriksa bahwa pengujian saya tidak dihapus oleh pengembang lain?

8

Saya baru saja menemukan masalah pengkodean kolaboratif yang menarik di tempat kerja.

Saya telah menulis beberapa tes unit / fungsional / integrasi dan mengimplementasikan fungsionalitas baru ke dalam aplikasi yang dapat ~ 20 pengembang mengerjakannya. Semua tes lulus dan saya memeriksa kode. Hari berikutnya saya memperbarui proyek saya dan memperhatikan (kebetulan) bahwa beberapa metode pengujian saya dihapus oleh pengembang lain (menggabungkan masalah pada akhirnya). Kode aplikasi baru tidak tersentuh.

Bagaimana saya bisa mendeteksi masalah seperti itu secara otomatis? Maksud saya, saya menulis tes untuk secara otomatis memeriksa bahwa kode saya masih berfungsi (atau tidak dihapus), bagaimana saya melakukan hal yang sama untuk tes?

Kami menggunakan Java, JUnit, Selenium, SVN dan Hudson CI jika itu penting.

— parxier
sumber

1

Saya bahkan tidak yakin bagaimana Anda "secara tidak sengaja" menghapus seluruh petak kode jika Anda benar-benar melakukan tarikan yang tepat -> menggabungkan -> melakukan hal.

— Anon.

@Anon Aku juga yakin, dia bilang dia terburu-buru dan perlu melakukan kode dengan cepat, jadi dia tidak terlalu memperhatikan penggabungan sesuatu atau sesuatu. : - / Pokoknya saya masih ingin mendeteksi masalah seperti itu secara otomatis di tingkat CI.

— parxier

10

Dan orang "yang sedang terburu-buru" mungkin perlu bicara diam-diam dari seorang manajer, perilaku seperti itu malas dan tidak boleh diterima.

— cepat_now

1

Saya hanya bisa membayangkan ini akan mungkin jika orang-orang memeriksa perubahan besar dengan banyak file yang dimodifikasi dalam waktu yang sangat lama. Anda seharusnya tidak memiliki gabungan besar di mana bahkan ada kemungkinan untuk kode yang akan "hilang" ... bahwa suara seperti nyata sumber masalah bagi saya.

— Dean Harding

1

Inilah sebabnya mengapa seorang pengembang individu tidak boleh diizinkan untuk bergabung ke trunk di VCSes terpusat. Malas dev memiliki kecenderungan untuk menghancurkan barang orang lain (bersalah sendiri).

— Chris K

4

Saya tidak terlalu akrab dengan Hudson untuk CI, tetapi alat CI saya juga dapat menghitung cakupan kode. Jika Anda dapat menulis proses yang akan memberi tahu Anda ketika cakupan kode turun, itu akan menjadi indikator yang baik bahwa tes telah dihapus. Ini juga akan memberi tahu Anda jika kode baru telah ditambahkan tanpa tes. Bukan apa yang Anda tanyakan, tapi senang tahu.

— Marcie
sumber

3

Saya akan menyebutkan hal ini dalam komentar tentang jawaban Tim: persentase cakupan kode Anda tidak boleh berkurang.

— Frank Shearar

Sudut yang bagus pada metrik!

Alat apa itu, mungkin?

— Chris K

@ Chris, kami menggunakan TFS + TeamBuild, yang telah saya konfigurasikan untuk menghitung cakupan kode pada setiap Build.

— Marcie

Itu tidak akan bekerja pada proyek khusus ini karena cakupan tes saat ini cukup rendah, jadi saya harus mencoba ide Tim. Tetapi Anda memberi saya solusi yang baik dan saya pikir itu adalah jawaban terbaik untuk pertanyaan saya.

— parxier

12

Penafian standar berlaku: kami membuat solusi rekayasa untuk masalah sosial. Namun, ini adalah masalah kebersihan proyek, jadi agak seperti mengatakan toilet adalah solusi rekayasa untuk masalah sosial.

Dapatkan pekerjaan dari feed RSS dari Hudson. Hitung jumlah tes dalam laporan Hudson. Jika berkurang, bunyikan alarm. Miliki fitur auto-da-fe 'saat alarm berbunyi.

Kesalahan komit dapat diidentifikasi dan dihukum. Masalahmu akan hilang.

Anda mungkin membuat masalah lain sebagai hasil dari solusi ini. Jika pusing berlanjut, silakan kunjungi dokter Anda.

— Tim Williscroft
sumber

1

+1: "kami membuat solusi rekayasa untuk masalah sosial". Itu harus menjadi akhir dari jawabannya. Sisa jawabannya kurang berharga dari satu pernyataan itu.

— S.Lott

2

@ SLott ya, tetapi jika Anda membuatnya mudah untuk melakukan hal yang benar, itu akan selesai. Kami telah menggunakan email otomatis untuk seluruh tim, yang dipicu oleh kerusakan build. Berhasil; Anda menjadi lebih berhati-hati. Saya pribadi meragukan kegunaan mencoba memecahkan masalah sosial ini. Jika Anda jujur menghapus tes tidak apa-apa, maka budaya perusahaan menentang kualitas.

— Tim Williscroft

Wow, saya orang Portugis, dan saya tidak tahu apa itu auto-da-fé.

— R. Martinho Fernandes

Jumlah tes dapat berkurang karena alasan yang valid: sebuah refactoring dapat menghapus kelas dan semua tes unitnya. Namun, masih ada baiknya mencari tahu mengapa jumlah tes turun.

— Frank Shearar

@ Sejujurnya saya kira apa yang penting jika seberapa sering jumlah tes turun untuk alasan yang valid dibandingkan dengan yang tidak valid. Jika itu sebagian besar alasan yang sah, maka alarm hanya akan diabaikan setelah sedikit dan menjadi tidak berharga. Jika sebagian besar tidak valid maka itu bisa baik. Seberapa sering ini terjadi? Dan sebenarnya, @parxier, jika itu hanya terjadi sekali yang Anda ketahui, mungkinkah Anda bereaksi berlebihan?

— James

2

Pendekatan organisasi

Siapkan kebijakan yang mengharuskan seseorang menghapus tes untuk berbicara dengan pembuat tes. Biasanya Anda akan menghapus tes hanya ketika mendepresiasi beberapa fungsi yang sedang diuji, dan itu tidak sering terjadi.

Pendekatan teknis

Ini lebih merupakan pendekatan control freak tetapi Anda dapat memiliki tes terpisah, yang memindai kode sumber untuk keberadaan semua tes yang ingin Anda periksa. Mungkin Anda juga bisa antarmuka Hudson dan mendapatkan daftar tes yang dieksekusi.

— Seni
sumber

Barang telah dihapus selama penggabungan. Mungkin karena kecelakaan, mungkin karena kemalasan. Kebijakan tidak akan melakukan banyak hal selain dari "kamu" dari manajemen yang semua orang akan abaikan. Namun, pembakaran dan cambukan publik mungkin mendapat perhatian. / sarcoff

— quick_now

2

@quickly_now: "Barang telah dihapus saat penggabungan". Itu harus menjadi pelanggaran tembak. Organisasi apa pun yang memungkinkan perilaku ini benar-benar perlu menghapus banyak orang dan menggantinya dengan orang-orang yang berupaya melakukan sesuatu yang masuk akal alih-alih kejahatan.

— S.Lott

Kecelakaan - Anda dapat memaafkannya pertama kali. Kemalasan atau kejahatan - ya - menyinggung pelanggaran.

— cepat_now

Akan sulit untuk membuat kelas tes yang terpisah tetap up-to-date, tetapi ini ide yang menarik, terima kasih.

— parxier

0

Mirip dengan jawaban Art ..

Komentar Mulai dengan menggunakan komentar dengan baik. Untuk setiap metode; jangan lupa untuk menempatkan input dan output yang diharapkan, deskripsi singkat untuk fungsi yang lebih kompleks dan nama Anda.

Pedoman Tetapi ini benar-benar menggarisbawahi bahwa ada kebutuhan untuk lebih banyak komunikasi antara dev. tim. Harus ada pedoman untuk bekerja bersama ... atau setidaknya berbicara dengan proj Anda. manajer dan memintanya untuk mengklarifikasi ini di antara tim.

Penggunaan SVN yang tepat Anda juga dapat menuliskan kelas dan metode Anda dan melacaknya .. juga saat Anda menggunakan SVN, saya sangat berharap bahwa penghapusan ini dilacak sebagai perubahan, dicatat secara terpisah dan memiliki alasan yang BAIK.

Pendek menulis program khusus, Anda juga bisa membandingkan diff. file di SVN untuk melacak perubahan pada metode Anda.

— Ross
sumber

0

Hal yang sama dapat terjadi untuk kode aktual juga, dan Anda tidak akan tahu sampai Anda melihat perubahan Anda tidak ada lagi.

Yang sedang berkata, sulit untuk mengidentifikasi kode yang dihapus sebagai hal yang buruk, karena sangat sering Anda secara manual menghapus kode / fitur dll, dan karena itu jumlah tes dapat turun serta orang lain yang disebutkan.

— ozz
sumber

Ketika kode dihapus, tes rusak. Ketika tes dihapus, tidak ada istirahat.

— parxier