Bagaimana saya harus menjadi sedikit otomatisasi: apa yang saya rasakan, selamat, dan arsitektur dan infrastruktur pengujian otomatis yang indah melalui mata seorang pengembang yang lewat.
Pendahuluan
Seperti yang mereka katakan, saya bukan seorang ginekolog, saya hanya berjalan dan memutuskan untuk melihat. Karena itu, sebagai permulaan, saya akan mengatakan tentang alasan penulisan. Tampak bagi saya bahwa seorang spesialis akan mengatasi masalah urutan besarnya lebih cepat dan tidak akan mengumpulkan sebanyak mungkin menyapu jalan. Tapi dia tidak akan tertarik seperti saya, dan Anda tidak akan punya apa-apa untuk dibaca.
Alasan lain yang membuat saya menulis: untuk sementara waktu saya tidak mengerti apa yang begitu istimewa tentang infrastruktur autotest. Selain itu, banyak manajer dari PM dan di atas juga tidak sepenuhnya memahami apa yang begitu kosmik di sana dan mengapa pengembang menulis tes unit untuk satu atau dua sendiri, dan untuk uji coba, individu diambil, yang menulis tes lebih lambat, terus memperbaiki sesuatu dan peluang untuk melewati semua spesifikasi keuangan sangat kurang dari 100%, asalkan sampelnya cukup besar.
Masalah
Pada hari ketiga, spek masalah pada proyek kereta api jatuh. Di suatu tempat seminggu sebelumnya, satu-satunya insinyur otomatisasi kami memutuskan untuk pergi bekerja di Chicago dan kami belum menemukan spesialis baru. Karena itu, saya harus menyingsingkan lengan baju saya dan berpura-pura menjadi QA. Tentang bagaimana itu dan coba katakan.
Masalahnya terlihat sangat tidak berbahaya. Tapi, sebagai permulaan, sedikit latar belakang dan deskripsi lingkungan. Kami memiliki banyak penyeleksi alamat di platform kami. Jujur, ini adalah salah satu entitas utama platform. Penyeleksi pergi ke google api untuk data. Dalam autotest, semua permintaan terhenti untuk menghemat uang dan mempercepat tes. Juga, sedikit logika telah ditambahkan untuk memberikan kira-kira garis alamat yang sama yang diminta tanpa pergi ke layanan eksternal.
Apa yang rusak: kita memasukkan alamat yang diinginkan di bilah alamat, kotak drop-down muncul dengan beberapa opsi, kita pilih yang diinginkan dan ... nilai elemen tetangga dimasukkan ke dalam input. Selalu.
Jauh menuju kebenaran
Hipotesis pertama dan pendekatan naif
Tanpa basa-basi lagi, saya mengambil tes jatuh terdekat, menemukan garis di mana alamat itu dipilih dan mulai memeriksanya dengan cermat dan tetangga. Baris tersebut tidak berbahaya: new_order_page.destination_address.select(baker_street) . Tapi kami mengerti bahwa di balik kode yang indah selalu ada banyak desain kecil yang aneh dan isi perut yang tidak menyenangkan.
Saya segera ingat bahwa semua ekonomi ini berfungsi di SitePrism . Hal ini memungkinkan untuk membungkus halaman dan elemen di dalamnya dalam kelas dan metode kelas, masing-masing. Untuk klik dan tindakan lainnya, Capybara dan RSpec bertanggung jawab. Tetapi mereka tidak ragu, mereka dapat diandalkan, seperti seluruh armada sipil. Dan jika demikian, hipotesis pertama segera menunjukkan dirinya: apakah seseorang dengan buruk menulis penyeleksi untuk prisma, atau seseorang memelintir tata letak di bagian depan.
Bagian pertama dari hipotesis dengan cepat menghilang, penyeleksi ditulis dengan sempurna. Tidak ada xpath dengan pilihan li ketiga di dalam elemen yang ditemukan di sana dan kode itu sendiri tidak berubah tahun lalu.
Namun, di bidang metode select , menumpuk logika dengan regexps untuk memilih opsi yang diinginkan dari daftar drop-down. Tentu saja, saya marah pada regexps dan pergi untuk memeriksanya. Saya menghabiskan setengah jam dan saya mengerti bahwa semuanya bekerja dengan baik. Tepat garis yang dibutuhkan dipilih. click disebut padanya. Dan semuanya harus bekerja. Artinya, bagian kedua dari hipotesis tata letak juga menghilang. Tetapi muncul pemikiran tentang kurva js . Setelah semua, elemen pada halaman yang kita miliki adalah custom, js di sekitarnya dalam urutan dan, apalagi, di js ini js saja bermain-main dengannya.
Js yang harus disalahkan
Ini adalah alasan standar untuk semua masalah yang tidak jelas. Sesuatu seperti "pergi ke js , karena dia sudah kaget." Dan, tampaknya, dalam kasus saya, juga tidak bisa melakukannya tanpa js . Secara umum, tanpa berpikir dua kali, saya berlari ke tim front-end dan mengarahkan jari saya pada tes jatuh, menyatakan "semuanya bekerja di pihak kami, tolong perbaiki sisi Anda."
Tapi, orang-orang dari pesolek itu tidak ketinggalan, mereka memilih di sana selama beberapa jam, menemukan beberapa bug yang tidak terkait dengan narasi dan mengatakan bahwa js tidak bisa disalahkan! Pada saat yang sama, mereka memunculkan informasi menarik bahwa satu permintaan untuk pemilihan tidak cukup dan dia membuat yang lain, jawaban yang sama persis dengan isi input yang salah.
Saya tidak mengharapkan perubahan seperti itu. Kita harus kembali dan mencari tahu bagaimana tiruan permintaan bekerja untuk kita.
Pendekatan komprehensif
Jadi, tidak ada tempat lain untuk menunggu bantuan, Moskow ada di belakang kami dan hal-hal seperti itu.
Pertama-tama, kita melihat cara permintaan Moka ke Google. Lebih tepatnya, pertama-tama kita mencari di mana ini terjadi. Ini bukan tugas sepele. Ternyata kami memiliki seluruh modul MockServices::Base , yang bertanggung jawab atas mock dari berbagai permintaan menggunakan VCR . Dia licik berlutut di pengontrol dasar dan hanya karena nama layanan yang bertanggung jawab untuk permintaan eksternal, dia tidak dapat ditemukan.
Oke, temukan moki. Sekarang kita lihat implementasinya. Permintaan pertama menjadi basah hanya: informasi dari params diambil dan diganti ke dalam template dengan jawabannya. Untuk berjaga-jaga, saya memeriksa isi params dan, seperti yang diharapkan, semuanya ada sebagaimana mestinya.
Metode moka dari permintaan berikutnya lebih menarik. Beberapa jenis mock_data muncul di sana. Ini bukan params dan kami harus mencari tahu dari mana tanggal ini berasal. Setelah jatuh lima kali ke dalamnya, terungkap bahwa data ini diambil dari RequestStore menggunakan kunci x_mock_data . Sudah lebih menarik.
Kami kembali ke pengujian awal dan melihat ada set_mock_header , yang, setelah diperiksa lebih dekat, menambahkan beberapa data ke RequestStore sama. Lebih menarik!
Di suatu tempat pada saat ini, disonansi kognitif terjadi di kepala: di satu sisi, itu kemungkinan penyebab masalah, variabel global yang diminta oleh pihak sampingan membuat kita bangkrut. Tetapi ada nuansa: server untuk spesifikasi keuangan dan spesifikasi keuangan itu sendiri adalah dua proses independen (pada kenyataannya, server setidaknya 3 proses), oleh karena itu, debit dengan kredit tidak dapat menyatu dengan cara apa pun, karena tidak ada variabel global antara proses telah dibawa ke dunia ini. Dan dengan server web multi-threaded, itu akan menjadi game yang sengit, yang tidak akan berfungsi secara fisik. Berarti saya melubangi sesuatu dan perlu untuk mencari.
Kami melihat lebih jauh dan menemukan bm tertentu, yang diletakkan tajuknya. Teruskan dan sadari bahwa bm adalah BrowserMob . Lalu saya mendapat sedikit mengutak-atik, karena itu adalah proxy di Jawa dalam bungkus ruby. Hanya piano di semak-semak.
Kami mulai memilih lebih jauh dan memahami bahwa untuk variabel "global" antara klien dengan rspec dan server dengan aplikasi (misalnya, puma ), header X-Mock-Data dalam permintaan digunakan. Masalahnya adalah aplikasi tersebut seharusnya tidak tahu apa-apa tentang pembaca ini. Hanya untuk ini, Anda memerlukan proxy tempat semua permintaan akan terbang dan yang akan mengatur header. Dengan cerdik, Anda tidak akan mengatakan apa-apa.
Kami pergi untuk menguji dan menemukan bahwa hal ini tidak berfungsi. Header tidak terlihat di mana pun: baik dalam permintaan maupun dalam respons. Tetapi RequestStore diisi di sisi rspec dan kosong di sisi server web. Itu berarti pasti - itu ada di proxy.
Kemudian, di antaranya, ternyata kita tidak hanya menguji dengan alamat yang set_mock_header , tetapi juga semua yang menggunakan set_mock_header atas.
Bagus Masih memahami bagaimana cara memperbaikinya.
Kami berurusan dengan proxy
Kami menghilangkan titik penggalian di wilayah tempat file jar diluncurkan dan kemudian mengontrolnya melalui Ruby. Lebih baik memperhatikan cara proxy browser ditentukan. Kami menggunakan Chrome dan meneruskan informasi proksi di salah satu dari banyak argumen dari baris perintah ketika dimulai. Fitur proxy adalah bahwa kami menggunakan file pac yang kami hasilkan dari template untuk mencegah lalu lintas dari soket web melalui proxy.
Di suatu tempat di sini ada keinginan untuk pergi dan mencari apa yang ada di chrome dengan konfigurasi proxy. Ternyata Anda tidak perlu melangkah jauh dan dalam versi 72+ orang-orang "menyelesaikan" pekerjaannya. Pada kesempatan ini, mereka bahkan membawa bug terpisah . Komentar favorit saya:
"Bisakah Anda berhenti MENGHAPUS fungsionalitas?"
Yang menyedihkan adalah bahwa itu dianggap sebagai fitur dan di masa depan mereka menjanjikan lebih banyak timah dalam hal "kerahasiaan".
Singkatnya, Chrome tidak lagi mendukung file: protokol dalam argumen proxy-pac-url . Solusi satu lebih baik daripada yang lain:
- berikan argumen
js yang akan membaca file pac dan mengubahnya menjadi base64: --proxy-pac-url='data:application/x-javascript-config;base64,'$(base64 -w0 /path/to/pac/script) ; - naikkan server web Anda dengan python untuk mendistribusikan satu file sesuai dengan protokol yang lebih "benar", yang didukung dalam argumen untuk proksi
pac ; - matikan
NetworkService dan kemudian file: protokol harus bekerja, tetapi mereka berjanji bahwa itu akan "diperbaiki" di masa depan juga.
Dua pilihan pertama tentu saja tidak menginspirasi saya, dan yang ketiga, anehnya, membantu.
Sukacita yang berumur pendek
Senang karena koneksi yang rumit ditemukan antara dropdown idle dan chrome yang diperbarui, saya tidak senang lama. Ternyata CI kami diperbarui tidak hanya chrome, tetapi juga semua paket yang berdekatan, dan sekarang kami memiliki lebih banyak tes yang Selenium::WebDriver::Error::NoSuchDriverError karena kesalahan yang tidak diketahui Selenium::WebDriver::Error::NoSuchDriverError , yang anehnya, tidak terkait dengan chromedriver , tetapi terkait dengan konfigurasi chrome, versi perpustakaan dan eksekusi spesifikasi paralel.
Tapi ini tugas untuk hari kerja berikutnya ...
Ke depan: argumen disable-dev-shm-usage membantu di sana.
Kesimpulan
Jangan memarahi otomatisasi. Dia tampaknya paling menderita dari keadaan eksternal yang tidak tergantung padanya.
Lebih baik berteman dengan insinyur otomatisasi dengan para dev, sehingga mereka mengatur infrastruktur mereka dengan preferensi dan pelacur dengan versi tetap dan lingkungan uji terkontrol. Bagi saya, ini lebih baik daripada menderita CI eksklusif, masing-masing memiliki kruk dan bangku bawah air yang sangat canggih, yang akan Anda pelajari hanya setelah integrasi aplikasi Anda yang ketat dan pengujian dengan lingkungan orang lain.