Pengujian integrasi tetap menjadi bagian penting dari siklus produksi CI / CD, termasuk pengembangan aplikasi kemas. Tes integrasi, sebagai suatu peraturan, tidak terlalu lama, tetapi sangat padat dengan sumber daya. Mari kita lihat bagaimana Anda dapat menggabungkan teknologi pengujian terintegrasi dan alat-alat dengan alat orkestrasi wadah (khususnya, dengan
Red Hat OpenShift ) untuk mempercepat pengujian, meningkatkan dinamismenya, dan menggunakan sumber daya lebih efisien.
Mari kita buat tes BDD integrasi (
pengembangan yang didorong oleh perilaku ) menggunakan
Mentimun , Busur Derajat dan
Selenium dan menjalankannya pada platform OpenShift menggunakan Zalenium.
Pengujian BDD
Dalam mengembangkan tes integrasi, BDD memungkinkan analis bisnis (BA) untuk membuat definisi tes integrasi, bukan hanya programmer. Berkat BDD, proses pengembangan dapat diatur sehingga persyaratan fungsional dan definisi tes integrasi disiapkan pada saat yang sama, dan pada saat yang sama dibuat oleh analis bisnis.
Ini jauh lebih baik daripada pendekatan tradisional, ketika Anda pertama kali menentukan fungsionalitas bisnis aplikasi, dan kemudian departemen QA membuat tes integrasi, seperti yang ditunjukkan pada diagram di bawah ini:
Dan inilah tampilannya saat menggunakan BDD:
Selain itu, dalam skema baru ini, setiap iterasi biasanya membutuhkan waktu lebih sedikit.
Analis bisnis dapat membuat definisi untuk tes integrasi karena BDD menjelaskan tes-tes ini dalam bahasa
Gherkin yang sederhana dan dapat dipahami yang kata kunci utamanya adalah Diberikan, Kapan, dan Lalu. Setiap pernyataan dalam bahasa Gherkin harus dimulai dengan salah satu dari kata-kata ini.
Sebagai contoh:Mengingat pengguna menavigasi ke halaman login (Asalkan pengguna telah mengakses halaman login)
Saat pengguna memasukkan nama pengguna dan kata sandi
Ketika nama pengguna dan kata sandi sudah benar
Kemudian sistem mencatatnya (Kemudian sistem memungkinkannya untuk masuk)Salah satu runtime populer yang dapat menginterpretasikan tes Gherkin adalah
Mentimun . Untuk menggunakan Timun, pengembang harus mengimplementasikan fungsi tertentu sehingga arahan Gherkin dapat dijalankan. Mentimun memiliki ikatan dengan banyak bahasa pemrograman. Tes disarankan (tetapi tidak wajib) ditulis dalam bahasa yang sama dengan aplikasi yang diuji.
Teknologi Pengujian Stack
Mari kita
lihat prosedur pengujian menggunakan aplikasi web
TodoMVC sebagai
contoh dalam
implementasi AngularJS . AngularJS adalah kerangka kerja populer untuk membuat Aplikasi Satu Halaman (SPA).
Karena AngularJS adalah JavaScript, kami akan menggunakan
Cumcumber.js , mentimun mengikat JavaScript.
Untuk meniru kerja pengguna di peramban, kami akan menggunakan
Selenium . Selenium adalah proses yang dapat meluncurkan browser dan memutar tindakan oleh pengguna atas perintah yang diterima melalui API.
Akhirnya, kami akan menggunakan
busur derajat untuk memperhitungkan nuansa meniru aplikasi SPA yang ditulis dalam AngularJS. Busur derajat akan menjaga harapan bahwa tampilan di dalam halaman dimuat dengan benar.
Jadi, tumpukan pengujian kami adalah sebagai berikut:
Proses yang disajikan dalam diagram ini dijelaskan sebagai berikut:
- Ketika tes Mentimun berjalan, Mentimun membaca definisi uji dari file Gherkin.
- Kemudian mulai memanggil kode implementasi kode tes.
- Kode Pelaksanaan Skrip Pengujian Menggunakan Busur Derajat untuk Melakukan Tindakan di Halaman Web
- Ketika ini terjadi, busur derajat terhubung ke server busur derajat dan mengeluarkan perintah ke Selenium melalui API.
- Selenium mengeksekusi perintah ini dalam instance browser.
- Browser, jika perlu, terhubung ke server web. Dalam contoh kami, aplikasi SPA digunakan, oleh karena itu, koneksi seperti itu tidak terjadi, karena aplikasi telah dimuat saat memuat dari server halaman pertama.
Menyebarkan tumpukan seperti itu dalam infrastruktur non-kemas tidaklah mudah. Dan bukan hanya karena banyaknya proses dan kerangka kerja yang digunakan, tetapi juga karena meluncurkan browser di server tanpa monitor selalu sulit. Untungnya, di dunia kemas, semua ini bisa otomatis.
Kebun Pengujian Integrasi
Aplikasi web perusahaan perlu diuji untuk berbagai kombinasi OS klien dan browser. Biasanya, ini terbatas pada serangkaian opsi dasar tertentu yang mencerminkan situasi pada mesin pengguna akhir aplikasi. Tetapi bahkan dalam kasus ini, jumlah konfigurasi pengujian untuk setiap aplikasi jarang turun di bawah setengah lusin.
Jika Anda secara konsisten menggunakan tumpukan untuk setiap konfigurasi tes dan menjalankan tes yang sesuai di atasnya, maka ini terlalu mahal dalam hal waktu dan sumber daya.
Idealnya, saya ingin menjalankan tes secara paralel.
Selenium-Grid dapat membantu kami dalam hal ini - solusi yang mencakup broker permintaan Selenium Hub dan satu atau lebih node tempat permintaan ini dijalankan.
Setiap Selenium-node, yang biasanya berjalan pada server yang terpisah, dapat dikonfigurasikan untuk kombinasi spesifik dari OS klien dan browser (dalam Selenium, ini dan karakteristik lain dari node disebut kemampuan - properti). Pada saat yang sama, Selenium Hub cukup pintar untuk mengirim permintaan yang membutuhkan properti Selenium tertentu ke node yang memiliki properti ini.
Cluster Selenium-Grid cukup sulit untuk diinstal dan dikelola, dan sangat banyak sehingga perusahaan yang menawarkan layanan terkait bahkan muncul di pasar. Secara khusus, SauceLabs dan BrowserStack adalah beberapa pemain utama.
Pengujian integrasi berbasis wadah
Sangat sering, saya ingin dapat membuat cluster Selenium-Grid yang akan menyediakan properti Selenium yang diperlukan untuk pengujian kami dan menjalankan tes sendiri dengan tingkat paralelisasi yang tinggi. Kemudian, setelah pengujian selesai, saya ingin dapat sepenuhnya menghancurkan cluster ini. Dengan kata lain, untuk mempelajari cara bekerja dengan cara penyedia kebun uji integrasi bekerja sendiri.
Bidang teknologi ini masih pada tahap awal pembentukan, namun, satu proyek sumber terbuka yang menjanjikan -
Zalenium - menawarkan sebagian dari yang kita butuhkan.
Zalenium menggunakan Hub yang dimodifikasi yang dapat membuat simpul sesuai permintaan dan menghancurkannya saat tidak diperlukan lagi. Zalenium saat ini hanya mendukung browser Chrome dan Firefox di platform Linux. Tetapi dengan munculnya node Windows untuk Kubernetes, dukungan untuk Explorer dan Edge pada Windows dapat muncul.
Jika Anda menyatukan semuanya, maka tumpukan teknologi adalah sebagai berikut:
Setiap oval dalam diagram adalah pod terpisah di Kubernetes. Polong pemain uji dan emulator bersifat sementara dan hancur pada akhir tes.
Melakukan tes integrasi dalam pipa CI / CD
Mari kita buat jalur pipa sederhana di Jenkins untuk menunjukkan bagaimana mengintegrasikan jenis pengujian integrasi ini ke seluruh proses manajemen rilis. Ini terlihat seperti ini:
Saluran pipa Anda mungkin beragam, tetapi Anda masih memiliki kesempatan untuk menggunakan kembali fase pengujian integrasi tanpa refactoring kode yang signifikan.
Karena sebagian besar perapian adalah fana, salah satu tugas pipa adalah untuk mengumpulkan hasil tes. Di Jenkins, ini dapat dilakukan dengan menggunakan arsip dan menerbitkan HTML primitif.
Dan ini adalah contoh laporan tentang hasil tes (perhatikan bahwa tes dijalankan pada dua browser):
Kesimpulan
Dengan demikian, terlepas dari kompleksitas pengorganisasian infrastruktur pengujian integrasi end-to-end, pendekatan “infrastruktur sebagai kode” menyederhanakan proses. Melakukan tes integrasi pada berbagai kombinasi OS dan browser membutuhkan banyak waktu dan sumber daya, tetapi alat orkestrasi kontainer dan beban kerja singkat membantu untuk mengatasi masalah ini.
Bahkan dengan tidak adanya alat yang matang untuk mengatur pengujian integrasi berorientasi kontainer, pengujian integrasi berdasarkan platform kontainer sudah dapat dilakukan hari ini dan mengambil keuntungan dari pendekatan kontainer.
Jika Anda mengembangkan aplikasi kemas, coba gunakan pendekatan ini dalam pipa CI / CD dan lihat apakah itu membantu menyederhanakan pengujian integrasi.
Kode contoh dari artikel ini dapat ditemukan di situs web GitHub di redhat-cop / container-pipelinesh.