Saya sedang menyelidiki teknik dan strategi untuk meningkatkan jumlah tes integrasi kami yang meningkat pada produk kami saat ini, sehingga mereka dapat (secara manusiawi) tetap menjadi bagian dari pengembangan kami, dan proses CI.
Pada sekitar 200+ tes integrasi, kami telah mencapai tanda 1 jam untuk menyelesaikan uji coba penuh (pada mesin desktop dev), dan ini secara negatif mempengaruhi kemampuan pengembang untuk mentolerir menjalankan seluruh rangkaian sebagai bagian dari proses push rutin. Yang memengaruhi motivasi untuk menjadi disiplin dalam menciptakan mereka dengan baik. Kami melakukan uji integrasi hanya skenario kunci depan ke belakang, dan kami menggunakan lingkungan yang mencerminkan produksi, yang dibangun dari awal setiap uji coba.
Karena waktu yang diperlukan untuk menjalankan, itu membuat loop umpan balik yang mengerikan dan banyak siklus terbuang menunggu mesin untuk menyelesaikan uji coba, tidak peduli seberapa fokus uji coba tersebut. Nevermind dampak negatif yang lebih mahal pada aliran dan kemajuan, kewarasan dan keberlanjutan.
Kami berharap memiliki tes integrasi 10 kali lipat lebih banyak sebelum produk ini mulai melambat (tidak tahu benar, tapi rasanya kami belum memulai dari segi fitur). Kita harus berharap untuk berada di beberapa ratus atau beberapa ribu tes integrasi, saya rasa di beberapa titik.
Agar lebih jelas, untuk mencegah hal ini menjadi diskusi tentang pengujian unit versus pengujian integrasi, (yang seharusnya tidak pernah diperdagangkan). Kami sedang melakukan kedua pengujian unit dengan pengujian TDD DAN integrasi di produk ini. Bahkan, kami melakukan pengujian integrasi pada berbagai lapisan dalam arsitektur layanan yang kami miliki, di mana masuk akal bagi kami, karena kami perlu memverifikasi di mana kami memperkenalkan pemecahan perubahan ketika mengubah pola dalam arsitektur kami ke area lain dari sistem.
Sedikit tentang tumpukan teknologi kami. Kami sedang menguji pada lingkungan emulasi (CPU dan memori) untuk menjalankan pengujian kami dari ujung ke ujung. Yang terdiri dari layanan web Azure REST yang menampilkan backend noSql (ATS). Kami mensimulasikan lingkungan produksi kami dengan menjalankan di Azure desktop Emulator + IISExpress. Kami terbatas pada satu emulator dan satu repositori backend lokal per mesin dev.
Kami juga memiliki CI berbasis cloud, yang menjalankan tes yang sama di lingkungan yang ditiru yang sama, dan uji coba berjalan dua kali lebih lama (2 jam +) di cloud dengan penyedia CI kami saat ini. Kami telah mencapai batas penyedia cloud CI SLA dalam hal kinerja perangkat keras, dan melampaui batas waktu uji coba. Agar adil bagi mereka, spesifikasi mereka tidak buruk, tetapi separuh lebih baik daripada mesin desktop muram inhouse jelas.
Kami menggunakan strategi pengujian untuk membangun kembali penyimpanan data kami untuk setiap kelompok logis pengujian, dan melakukan preloading dengan data uji. Sementara memastikan integritas data secara komprehensif, ini menambahkan dampak 5-15% pada setiap pengujian. Jadi kami pikir ada sedikit yang bisa diperoleh mengoptimalkan strategi pengujian pada saat ini dalam pengembangan produk.
Panjang dan pendeknya adalah bahwa: sementara kita dapat mengoptimalkan throughput setiap tes (meskipun masing-masing sebanyak 30% -50%), kita masih tidak akan skala secara efektif dalam waktu dekat dengan beberapa ratus tes. 1 jam sekarang bahkan masih jauh melebihi toleransi manusia, kita membutuhkan urutan peningkatan besar-besaran dalam proses keseluruhan untuk membuatnya berkelanjutan.
Jadi, saya sedang menyelidiki teknik dan strategi apa yang dapat kami terapkan untuk secara drastis mengurangi waktu pengujian.
- Menulis lebih sedikit tes bukanlah suatu pilihan. Tolong jangan berdebat yang ada di utas ini.
- Menggunakan perangkat keras yang lebih cepat jelas merupakan suatu pilihan, meskipun sangat mahal.
- Menjalankan kelompok pengujian / skenario pada perangkat keras terpisah secara paralel juga merupakan opsi yang lebih disukai.
- Membuat pengelompokan pengujian di sekitar fitur dan skenario yang sedang dikembangkan adalah masuk akal, tetapi pada akhirnya tidak dapat diandalkan dalam membuktikan cakupan penuh atau keyakinan bahwa sistem tidak terpengaruh oleh perubahan.
- Berjalan di lingkungan pementasan berskala awan alih-alih berjalan di emulator desktop secara teknis dimungkinkan, meskipun kami mulai menambahkan waktu penempatan untuk menguji proses (~ masing-masing 20 menit di awal pengujian untuk menyebarkan barang-barang).
- Membagi komponen-komponen sistem menjadi potongan-potongan log independen masuk akal sampai tingkat tertentu tetapi kami berharap jarak tempuh yang terbatas pada hal itu, karena interaksi antara komponen-komponen diharapkan meningkat seiring waktu. (Yaitu perubahan yang cenderung mempengaruhi orang lain dalam cara yang tidak terduga - seperti yang sering terjadi ketika suatu sistem dikembangkan secara bertahap)
Saya ingin melihat strategi (dan alat) apa yang digunakan orang lain di ruang ini.
(Saya harus percaya orang lain mungkin melihat kesulitan seperti ini menggunakan perangkat teknologi tertentu.))
[Pembaruan: 12/16/2016: Kami akhirnya berinvestasi lebih banyak dalam pengujian paralel CI, untuk diskusi tentang hasilnya: http://www.mindkin.co.nz/blog/2015/12/16/16-jobs]