Bagaimana menjaga kestabilan batang saat tes membutuhkan waktu lama?

9

Kami memiliki tiga set suite uji:

Suite "kecil", hanya membutuhkan beberapa jam untuk berlari
Suite "sedang" yang membutuhkan waktu beberapa jam, biasanya berlari setiap malam (setiap malam)
Suite "besar" yang membutuhkan waktu + minggu untuk beroperasi

Kami juga memiliki banyak suite tes yang lebih pendek, tapi saya tidak fokus pada mereka di sini.

Metodologi saat ini adalah menjalankan suite kecil sebelum setiap komit ke trunk. Kemudian, suite menengah berjalan setiap malam, dan jika pada pagi hari ternyata gagal, kami mencoba untuk mengisolasi mana dari komitmen kemarin yang harus disalahkan, kembalikan yang melakukan dan coba lagi pengujian. Proses serupa, hanya pada frekuensi mingguan dan bukan malam hari, dilakukan untuk suite besar.

Sayangnya, suite menengah gagal cukup sering. Itu berarti bahwa bagasi sering tidak stabil, yang sangat menjengkelkan ketika Anda ingin membuat modifikasi dan mengujinya. Ini menjengkelkan karena ketika saya check out dari bagasi, saya tidak tahu pasti itu stabil, dan jika tes gagal saya tidak tahu pasti apakah itu salah saya atau tidak.

Pertanyaan saya adalah, adakah metodologi yang diketahui untuk menangani situasi semacam ini dengan cara yang akan membuat bagasi selalu dalam kondisi prima? misalnya "komit ke cabang precommit khusus yang kemudian akan memperbarui trunk secara berkala setiap kali malam berlalu".

Dan apakah itu penting jika itu adalah sistem kontrol sumber terpusat seperti SVN atau yang didistribusikan seperti git?

Ngomong-ngomong aku adalah pengembang junior dengan kemampuan terbatas untuk mengubah banyak hal, aku hanya mencoba memahami jika ada cara untuk mengatasi rasa sakit yang aku alami ini.

— ek
sumber

6

Saya tidak tahu perangkat lunak apa yang sedang Anda kerjakan, tetapi sebuah test suite kecil yang membutuhkan waktu berjam-jam untuk dijalankan adalah beberapa WTF. Jika mereka berjalan lebih cepat, ini akan lebih mudah, tidak ada cara untuk merampingkan tes Anda?

— Benjamin Bannier

2

apa yang "sangat menjengkelkan" tentang bagasi yang tidak stabil? Tidak tahu jika Anda tahu, tetapi salah satu strategi percabangan yang paling populer bahkan disebut batang tidak stabil

— nyamuk

1

Ada banyak cara untuk mengoptimalkan test suite (seperti untuk perangkat lunak lain). Saya tidak tahu mengapa waktu Anda begitu lama, tetapi Anda mungkin dapat menggunakan kembali beberapa lingkungan pengujian atau hanya menggunakan algoritme / struktur data yang lebih baik saat menjalankan (profiling membantu). Mungkin juga tidak ada yang meluangkan waktu untuk mengidentifikasi sampel yang representatif dan Anda hanya menguji setiap input / output yang mungkin terhadap beberapa referensi. Mungkin sistem builds Anda memungkinkan Anda untuk menyandikan dependensi kode-tes sehingga Anda tidak perlu menjalankan set lengkap. Dan saya tahu ini bukan pertanyaan Anda, itu sebabnya saya berkomentar, bukan jawaban.

— Benjamin Bannier

1

... hmm, opsi Anda yang lebih baik kemungkinan akan meningkatkan pengujian dan pendataan aplikasi sehingga lebih mudah untuk menemukan alasan kegagalan. Dengan begitu, orang perlu menemukan dan memperbaiki penyebab kegagalan alih-alih menyia-nyiakan upaya "penyelidikan detektif" untuk mencari siapa, kapan dan mengapa mengubah jalur kode tertentu ...

— Agak

1

@honk Beberapa tes hanya membutuhkan waktu lama untuk dijalankan. Saya bekerja untuk perusahaan yang membuat peralatan akuisisi data dan uji coba "parsial" kami memakan waktu sekitar satu jam. Tes perlu melakukan berbagai jenis pengukuran dan itu hanya membutuhkan waktu.

— Velociraptors

1

Satu-satunya cara untuk memperbaiki akar penyebab ketidakstabilan adalah dengan memisahkan kode sehingga perubahan lebih terisolasi, seperti yang disarankan oleh jawaban lain.

Namun, sebagai pengembang individu, jika Anda ingin membangun yang lebih stabil untuk Anda kerjakan secara pribadi, itu relatif mudah dipecahkan. Alih-alih bekerja dari ujung, Anda hanya menarik bangunan terakhir yang melewati test suite semalam ke pohon kerja Anda. Jika Anda bisa membuat cabang fitur untuk setiap perubahan, maka cabut cabang dari bangunan stabil terakhir.

Ya, pohon Anda akan tertinggal beberapa hari, tetapi sebagian besar waktu itu tidak masalah. Lakukan pekerjaan Anda terhadap bangunan stabil, sehingga Anda tahu perubahan Anda adalah orang-orang yang melanggar tes apa pun, lalu sebelum Anda check-in, perbarui ke yang terbaru dan lakukan integrasi normal Anda. Kemudian setelah Anda check-in, kembali ke kandang terakhir.

Anda masih harus melakukan pekerjaan integrasi yang berantakan, tetapi apa yang saya sukai dari metode ini adalah mengisolasi pekerjaan integrasi ke waktu yang lebih nyaman bagi saya, dan memberi saya basis kode yang stabil untuk pengembangan ketika tidak nyaman. Saya punya ide yang jauh lebih baik ketika perubahan saya yang kemungkinan merusak build versus milik orang lain.

— Karl Bielefeldt
sumber

1

-1 bekerja dari cabang adalah pilihan yang layak, tetapi merekomendasikannya tanpa saran untuk diuji bisa lebih berbahaya daripada kebaikan. Hanya pengujian yang dapat menunjukkan apakah layak untuk proyek tertentu atau tidak. Misalnya dalam sebuah proyek yang saya lakukan sekitar 2 tahun yang lalu, pengujian seperti itu telah menunjukkan bahwa bekerja dari cabang memerlukan ~ 7 kali lebih banyak upaya dibandingkan dengan batang yang tidak stabil

— nyamuk

Terima kasih Karl! Meskipun ini bukan yang saya harapkan untuk dipelajari, ini adalah pendekatan yang sangat praktis yang dapat membantu saya memecahkan masalah yang ada. Dan saya setuju bahwa bekerja beberapa hari di belakang bagasi jarang menyebabkan masalah integrasi.

— Oak

12

Saya tahu Anda mencoba menghindari ini, tetapi wawasan sebenarnya di sini adalah untuk menyadari bahwa ada sesuatu yang salah dengan basis kode Anda: Anda perlu menjalankan serangkaian pengujian yang membutuhkan waktu seminggu hanya untuk memastikan kode Anda stabil!

Cara yang paling menguntungkan untuk memperbaiki masalah ini adalah mulai memisahkan basis kode Anda dan menguji menjadi sub-unit (independen).
Ada keuntungan besar untuk ini:

Tes untuk masing-masing unit akan berjalan lebih cepat (hanya ada sedikit dari mereka), dan mereka tidak akan rusak jika ada yang salah di salah satu unit independen atau hilir.
Tes yang gagal akan menunjuk ke unit tertentu yang akan membuatnya lebih mudah untuk menemukan sumber masalah.
Anda dapat memisahkan lokasi VCS dari unit yang berbeda sehingga cabang "stable" Anda dapat memilih dan menggabungkan bangunan yang berhasil teruji dari setiap unit, sehingga satu atau dua unit yang rusak tidak mengganggu kestabilan versi "stable" Anda. .

Pada manajemen flipside dari struktur VCS Anda akan menjadi lebih rumit, tetapi pada minggu penuh untuk tes penuh Anda, saya pikir Anda bisa menahan rasa sakit!

Saya masih merekomendasikan menggunakan strategi cabang "stabil" dan "pengembangan" dalam beberapa bentuk atau lainnya, tetapi ada banyak cara untuk melakukannya dan Anda dapat memilih yang paling cocok untuk organisasi Anda (repositori meta dengan revisi tetap yang menunjuk ke repositori terpisah untuk setiap unit, cabang stabil dan cabang dev, cabang fitur ....)

— Joris Timmermans
sumber

1

Saya tidak pernah mengatakan tes besar adalah tes atom, ini adalah test suite . Ketika seorang pengembang individu membuat modifikasi ke elemen X, ia menjalankan tes yang relevan dengan X - tidak peduli dari mana paket tes mereka berasal. Ini merupakan tambahan untuk tes mingguan, yang dijalankan untuk memastikan bahwa perubahan di satu tempat tidak terduga mempengaruhi tempat lain. Tetapi Anda membuat poin menarik bahwa setidaknya memisahkan hal-hal dengan cara ini akan membantu mempercepat tes untuk modul-modul tertentu, sambil menjaga risiko pada tingkat yang kira-kira sama.

— Oak

2

@ oak - Yah, dengan cara suite IS atom jika menjalankan semua itu adalah satu-satunya cara Anda benar-benar yakin bahwa kodenya stabil, tetapi Anda membuat poin yang baik, jadi saya sudah mengedit jawaban saya.

— Joris Timmermans

4

Kami memiliki testuites yang sangat besar untuk kompiler kami, beberapa di antaranya membutuhkan waktu beberapa hari untuk dijalankan, dan saya rasa itu tidak biasa untuk perangkat lunak serumit kompiler C ++. Ini bukan berarti bahwa suite mendefinisikan apa yang dianggap sebagai "stabil", tetapi bahwa ada jutaan cornercase berbeda dari pembuatan kode yang tidak mungkin untuk diuji setiap hari.

— JesperE

1

@JesperE - itu bisa dimengerti, jika test suite besar tidak mendefinisikan "stabil" tetapi merupakan tes kewarasan raksasa. Saya tidak akan mengharapkan suite lengkap (atau bahkan suite menengah) gagal sangat sering.

— Joris Timmermans

1

Untuk SVN, saya tidak tahu tentang hal seperti "pra-komit". Saya pikir ini cenderung menghasilkan komit dan kembalikan ketika tes gagal. Seperti yang dikatakan doc-brown, satu-satunya cara ada untuk melakukan pada cabang sementara dan menggabungkannya dengan bagasi nanti.

Menggunakan yang didistribusikan seperti git atau lincah, saya pikir itu mungkin. Menggunakan repositori "pengujian" dan repositori "stabil". Anda mendorong rep tes, menguji setiap malam, dan jika semuanya berjalan dengan baik, Anda mendorong dari tes ke stabil. Jika tidak, Anda mengembalikan rep pengujian. Saya agak tidak yakin bagaimana sejarah versi akan terlihat ketika Anda mendorong dari pengujian ke stabil, tapi saya pikir itu mungkin untuk mengecualikan hal-hal yang rusak rollback saat melakukannya. Sedikit bereksperimen terlebih dahulu akan menjadi yang paling aman.

Alternatif lain adalah dengan menguji batang lokal setiap orang setiap malam. Kemudian, orang-orang dengan tes yang lulus diizinkan untuk mendorongnya ke server pusat di pagi hari.

— dagnelies
sumber

1

IMHO ini tidak ada hubungannya dengan VCS yang Anda gunakan. Menggunakan cabang "sedang diuji" mungkin solusi, yang dapat direalisasikan dengan VCS terpusat atau didistribusikan juga. Tapi jujur, saya pikir hal terbaik dalam situasi Anda adalah mencoba untuk mengoptimalkan test suite menengah (tampaknya berisi tes yang paling penting) sehingga berjalan lebih cepat, jadi dan Anda dapat menggunakannya untuk pra-komit-ke-trunk tes, sama seperti Anda melakukannya sekarang dengan "suite kecil" Anda.

— Doc Brown
sumber

Saya kebanyakan bertanya tentang metodologi di sini - yaitu, apakah ada cara umum untuk menghadapi situasi seperti itu. Mari kita asumsikan, setidaknya untuk diskusi ini, bahwa tes tidak dapat dioptimalkan melebihi apa yang sudah ada.

— Oak

@Oak: seseorang di sini (Anda?) Memilih jawaban saya - tetapi kadang-kadang hal yang tidak ingin Anda dengar adalah satu-satunya hal yang akan membantu. Seperti yang Anda lihat dalam diskusi di bawah pertanyaan Anda, orang lain menyarankan hal yang sama, jadi saran saya sepertinya tidak terlalu buruk sama sekali.

— Doc Brown

+1, ini adalah jawaban yang tepat. Pertanyaan sebenarnya OP adalah "Tolong, saya tenggelam dalam omong kosong, metodologi apa yang bisa saya gunakan untuk membantu diri saya sendiri?" dan jawabannya adalah bahwa sebenarnya bukan metodologi yang harus Anda khawatirkan.

— MrFox

1

Tes sedang gagal: Apakah benar bahwa sebagian besar waktu tes yang sama gagal?

Jika ada kegagalan, apakah selalu ada tes terkait yang sama yang gagal?

Jika benar: Mungkin Anda dapat secara selektif memilih beberapa tes menengah yang sering gagal (satu tes untuk setiap kelas kesalahan) dan menjalankannya dalam set kecil.

Apakah sebagian besar tes integrasi-tes yang menggunakan database nyata? Jika demikian, mungkinkah untuk menggantinya dengan unittest yang memiliki database-mocked?

— k3b
sumber

1

Anda perlu membuat tes Anda berjalan lebih cepat, tidak ada cara lain untuk menyelesaikan lingkaran ini.

Pertimbangkan masalahnya: Anda ingin memastikan bahwa ketika Anda check out, Anda memiliki kode yang berfungsi. Tentu, Anda dapat menunda komit dan melakukan percabangan sampai sebelum rilis, tetapi itu hanya akan menunda timbulnya masalah sampai integrasi. Seperti dalam, apakah Anda harus menjalankan suite selama seminggu setelah setiap penggabungan? Metodologi bukan solusinya, solusi itu murni teknis.

Inilah yang saya sarankan:

1) Jadikan tes serumah mungkin, dan maksimalkan penggunaan kembali lingkungan.

2) Dapatkan lahan uji-suite untuk menjalankannya. Jika daripada 8 modul besar Anda berakhir dengan 50, Anda dapat memutar banyak instance Amazon EC2 dan menjalankan seluruh rangkaian secara paralel. Saya yakin ini membutuhkan biaya, tetapi akan menghemat banyak waktu pengembang.

— MrFox
sumber

0

Hal utama yang Anda anggap remeh dalam pertanyaan Anda adalah bahwa semua komitmen harus lulus tes. Meskipun ini adalah aturan yang baik untuk diikuti dan tampaknya masuk akal, kadang-kadang itu tidak praktis. Kasus Anda adalah contoh (meskipun MadKeithV benar,) dan saya bisa membayangkan memiliki cabang VCS sehingga murni bisa sulit jika tidak ada kerja sama yang cukup di antara para penyembah.

Kenyataannya apa yang Anda inginkan adalah entah bagaimana mengetahui mana yang lulus atau gagal. "Cabang pra-komit" seperti yang Anda sarankan akan berhasil, tetapi itu mungkin membutuhkan upaya ekstra dari pengembang ketika mereka membuat komitmen, yang mungkin sulit untuk dijual.

Pendekatan serupa yang bisa lebih mudah adalah meninggalkan bagasinya agar orang-orang dapat istirahat sesuka mereka, dan memiliki cabang untuk melakukan yang tidak rusak. Sebuah skrip otomatis dapat melewati komit saat dibuat ke bagasi, menjalankan tes pada mereka dan menambahkannya ke cabang jika lulus.

Atau Anda bisa menjadi sangat sederhana dan memiliki skrip yang mencantumkan komit yang lewat dalam file teks (yang mungkin atau mungkin tidak sendiri dikendalikan oleh versi).

Atau memiliki sistem batch yang menerima permintaan cabang / revisi untuk diuji (dari mana saja di pohon), dan mengujinya dan memasukkannya ke bagasi (atau cabang lain) jika lulus.

— Michael Slade
sumber