Perjalanan Pengujian E2E Bagian 2: WebdriverIO ke Cypress

Catatan: Ini adalah kiriman dari #frontend@twiliosendgrid. Untuk posting teknik lainnya, buka gulungan blog teknis.

Di semua aplikasi frontend kami, kami memiliki, dan masih memiliki, tujuan berikut: menyediakan cara untuk menulis pengujian otomatisasi E2E (end to end) yang konsisten, dapat di-debug, dipelihara, dan berharga untuk aplikasi frontend kami dan berintegrasi dengan CICD (integrasi berkelanjutan dan penyebaran berkelanjutan).

Untuk mencapai keadaan yang kami miliki saat ini di mana ratusan tes E2E mungkin dipicu atau berjalan sesuai jadwal di semua tim frontend kami di SendGrid, kami harus meneliti dan bereksperimen dengan banyak solusi potensial di sepanjang jalan sampai kami mencapai yang utama sasaran.

Kami mencoba meluncurkan solusi Ruby Selenium kustom kami sendiri yang dikembangkan oleh teknisi pengujian khusus yang disebut SiteTestUI alias STUI, di mana semua tim dapat berkontribusi pada satu repo dan menjalankan pengujian otomatisasi lintas-browser. Sayangnya, ia menyerah pada tes yang lambat dan terkelupas, alarm palsu, kurangnya konteks antara repo dan bahasa, terlalu banyak tangan dalam satu keranjang, pengalaman debugging yang menyakitkan, dan lebih banyak waktu yang dihabiskan untuk pemeliharaan daripada memberikan nilai.

Kami kemudian bereksperimen dengan perpustakaan lain yang menjanjikan di WebdriverIO untuk menulis tes dalam JavaScript yang ditempatkan dengan repo aplikasi masing-masing tim. Meskipun hal ini memecahkan beberapa masalah, memberdayakan lebih banyak kepemilikan tim, dan memungkinkan kami untuk mengintegrasikan pengujian dengan Buildkite, penyedia CICD kami, kami masih memiliki pengujian tidak stabil yang sulit untuk di-debug dan sulit untuk ditulis selain berurusan dengan semua bug dan kebiasaan Selenium yang terlalu mirip .

Kami ingin menghindari STUI 2.0 lain dan mulai menjelajahi opsi lain. Jika Anda ingin membaca lebih lanjut tentang pelajaran dan strategi kami yang ditemukan selama bermigrasi dari STUI ke WebdriverIO, lihat bagian 1 dari seri posting blog.

Di bagian kedua seri posting blog terakhir ini, kami akan membahas perjalanan kami dari STUI dan WebdriverIO ke Cypress dan bagaimana kami melakukan migrasi serupa dalam menyiapkan infrastruktur keseluruhan, menulis tes E2E terorganisir, mengintegrasikan dengan pipeline Buildkite kami, dan menskalakan ke tim frontend lainnya dalam organisasi.

TLDR: Kami mengadopsi Cypress daripada STUI dan WebdriverIO dan kami mencapai semua tujuan kami untuk menulis tes E2E yang berharga untuk diintegrasikan dengan CICD. Banyak pekerjaan dan pelajaran kami dari WebdriverIO dan STUI terbawa dengan baik ke dalam cara kami menggunakan dan mengintegrasikan tes Cypress hari ini.

Daftar isi

Menjelajah dan Mendarat di Cypress

Beralih dari STUI dan WebdriverIO ke Cypress

Langkah 1: Menginstal Dependensi untuk Cypress

Langkah 2: Konfigurasi dan Skrip Lingkungan

Pass Pertama dari Konfigurasi dan Skrip Lingkungan

Evolusi Konfigurasi dan Skrip Lingkungan

Langkah 3: Menerapkan tes E2E secara lokal

Langkah 4: Dockerizing tes

Langkah 5: Mengintegrasikan dengan CICD

Langkah 6: Membandingkan Cypress vs. WebdriverIO/STUI

Langkah 7: Menskalakan ke Tim Frontend Lainnya

Apa yang kami nantikan dengan Cypress

Mengadopsi Cypress ke Masa Depan

Menjelajah dan Mendarat di Cypress

Ketika kami mencari alternatif untuk WebdriverIO, kami melihat pembungkus Selenium lainnya seperti Protractor dan Nightwatch dengan fitur serupa yang disetel ke WebdriverIO, tetapi kami merasa kemungkinan besar kami akan mengalami penyiapan yang lama, pengujian yang tidak stabil, dan debugging dan pemeliharaan yang membosankan di kemudian hari.

Untungnya, kami menemukan kerangka kerja pengujian E2E baru yang disebut Cypress, yang menampilkan pengaturan cepat, pengujian cepat dan dapat di-debug yang dijalankan di browser, penghentian permintaan lapisan jaringan, dan yang paling penting, tidak menggunakan Selenium di bawah tenda.

Kami mengagumi fitur luar biasa seperti rekaman video, GUI Cypress, Layanan Dasbor berbayar, dan paralelisasi untuk dicoba. Kami bersedia berkompromi pada dukungan lintas-browser demi pengujian berharga yang lulus secara konsisten terhadap Chrome dengan repertoar alat yang kami miliki untuk menerapkan, men-debug, dan memelihara pengujian untuk pengembang dan QA kami.

Kami juga menghargai kerangka pengujian, pustaka pernyataan, dan semua alat lain yang dipilih agar kami memiliki pendekatan yang lebih standar untuk pengujian di semua tim frontend kami. Di bawah ini, kami menyediakan tangkapan layar perbedaan antara solusi seperti WebdriverIO dan Cypress dan jika Anda ingin melihat lebih banyak perbedaan antara solusi Cypress dan Selenium, Anda dapat melihat dokumentasi mereka tentang cara kerjanya.

Dengan mengingat hal itu, kami berkomitmen untuk menguji Cypress sebagai solusi lain untuk menulis pengujian E2E yang cepat, konsisten, dan dapat di-debug untuk akhirnya diintegrasikan dengan Buildkite selama CICD. Kami juga sengaja menetapkan tujuan lain untuk membandingkan Cypress dengan solusi berbasis Selenium sebelumnya untuk akhirnya menentukan berdasarkan titik data apakah kami harus terus mencari atau membangun rangkaian pengujian kami dengan Cypress ke depan. Kami berencana untuk mengonversi pengujian WebdriverIO yang ada dan pengujian prioritas tinggi lainnya yang masih dalam STUI ke pengujian Cypress dan membandingkan pengalaman pengembang, kecepatan, stabilitas, waktu pengujian, dan pemeliharaan pengujian kami.

Beralih dari STUI dan WebdriverIO ke Cypress

Saat beralih dari STUI dan WebdriverIO ke Cypress, kami menanganinya secara sistematis melalui strategi tingkat tinggi yang sama yang kami gunakan ketika kami mencoba migrasi dari STUI ke WebdriverIO di repo aplikasi frontend kami. Untuk detail lebih lanjut tentang bagaimana kami menyelesaikan langkah-langkah tersebut untuk WebdriverIO, silakan merujuk ke bagian 1 dari seri posting blog. Langkah-langkah umum untuk transisi ke Cypress melibatkan hal berikut:

1. Menginstal dan menyiapkan dependensi untuk terhubung dengan Cypress
2. Menetapkan konfigurasi lingkungan dan perintah skrip
3. Menerapkan tes E2E yang lulus secara lokal terhadap lingkungan yang berbeda
4. Dockerizing tes
5. Mengintegrasikan pengujian Dockerized dengan Buildkite, penyedia CICD kami

Untuk mencapai tujuan sekunder kami, kami juga menambahkan langkah ekstra untuk membandingkan Cypress dengan solusi Selenium sebelumnya dan untuk akhirnya menskalakan Cypress di semua tim frontend dalam organisasi:

6. Membandingkan Cypress dalam hal pengalaman pengembang, kecepatan, dan stabilitas pengujian vs. WebdriverIO dan STUI
7. Menskalakan ke tim frontend lainnya

Langkah 1: Menginstal Dependensi untuk Cypress

Untuk bangun dan berjalan dengan cepat dengan Cypress, yang harus kami lakukan hanyalah `npm install cypress` ke dalam proyek kami dan memulai Cypress untuk pertama kalinya agar secara otomatis diletakkan dengan file konfigurasi `cypress.json` dan folder cypress dengan perlengkapan pemula, tes, dan file pengaturan lainnya untuk perintah dan plugin. Kami menghargai bagaimana Cypress dibundel dengan Mocha sebagai test runner, Chai untuk asersi, dan Chai-jQuery dan Sinon-Chai untuk asersi yang lebih banyak lagi untuk digunakan dan dirangkai. Kami tidak lagi harus menghabiskan banyak waktu untuk meneliti tentang test runner, reporter, pernyataan, dan pustaka layanan apa yang akan dipasang dan digunakan dibandingkan dengan saat kami pertama kali memulai dengan WebdriverIO atau STUI. Kami segera menjalankan beberapa tes yang dihasilkan dengan Cypress GUI mereka dan menjelajahi banyak fitur debugging yang kami miliki seperti debugging perjalanan waktu, taman bermain pemilih, video yang direkam, tangkapan layar, log perintah, alat pengembang browser, dll.

Kami juga mengaturnya nanti dengan Eslint dan TypeScript untuk pemeriksaan tipe statis ekstra dan aturan pemformatan yang harus diikuti saat melakukan kode pengujian Cypress baru. Kami awalnya memiliki beberapa masalah dengan dukungan TypeScript dan beberapa file yang membutuhkan file JavaScript seperti yang berpusat di sekitar file plugin, tetapi untuk sebagian besar kami dapat mengetik periksa sebagian besar file kami untuk pengujian, objek halaman, dan perintah kami.

Berikut adalah contoh struktur folder yang diikuti oleh salah satu tim frontend kami untuk menggabungkan objek halaman, plugin, dan perintah:

Langkah 2: Konfigurasi dan Skrip Lingkungan

Setelah menginstal dan menyiapkan Cypress dengan cepat untuk dijalankan secara lokal, kami membutuhkan cara agar pengujian Cypress kami dapat berjalan dengan berbagai pengaturan untuk setiap lingkungan dan ingin mendukung kasus penggunaan yang sama yang diizinkan oleh perintah WebdriverIO kami. Berikut adalah daftar yang menggambarkan sebagian besar kasus penggunaan tentang bagaimana kami ingin menjalankan pengujian ini dan mengapa kami ingin mendukungnya:

• Terhadap server dev Webpack yang berjalan di localhost (yaitu http://localhost:8000) dan server dev tersebut akan diarahkan ke API lingkungan tertentu (yaitu https://testing.api.com atau https://staging.api. com) seperti pengujian atau pementasan.
  Mengapa? Terkadang kami perlu membuat perubahan pada aplikasi web lokal kami seperti menambahkan pemilih yang lebih spesifik agar pengujian kami dapat berinteraksi dengan elemen dengan cara yang lebih kuat atau kami sedang mengembangkan fitur baru dan perlu menyesuaikan dan memvalidasi pengujian otomatisasi yang ada akan diteruskan secara lokal terhadap perubahan kode baru kami. Setiap kali kode aplikasi berubah dan kami belum mendorong ke lingkungan yang diterapkan, kami menggunakan perintah ini untuk menjalankan pengujian kami terhadap aplikasi web lokal kami.
• Terhadap aplikasi yang diterapkan untuk lingkungan tertentu (yaitu https://testing.app.com atau https://staging.app.com) seperti pengujian atau pementasan
  Mengapa? Di lain waktu kode aplikasi tidak berubah tetapi kami mungkin harus mengubah kode pengujian kami untuk memperbaiki beberapa kelemahan atau kami merasa cukup percaya diri untuk menambah atau menghapus pengujian sama sekali tanpa membuat perubahan frontend. Kami banyak menggunakan perintah ini untuk memperbarui atau men-debug pengujian secara lokal terhadap aplikasi yang diterapkan untuk mensimulasikan lebih dekat bagaimana pengujian kami berjalan di CICD.
• Berjalan dalam wadah Docker terhadap aplikasi yang diterapkan untuk lingkungan tertentu seperti pengujian atau pementasan
  Mengapa? Ini dimaksudkan untuk CICD sehingga kami dapat memicu pengujian E2E untuk dijalankan dalam container Docker, misalnya, untuk staging aplikasi yang di-deploy dan memastikannya lulus sebelum menerapkan kode ke produksi atau dalam pengujian terjadwal dalam pipeline khusus. Saat mengatur perintah ini pada awalnya, kami melakukan banyak percobaan dan kesalahan untuk memutar wadah Docker dengan nilai variabel lingkungan yang berbeda dan menguji untuk melihat pengujian yang tepat berhasil dijalankan sebelum menghubungkannya dengan penyedia CICD kami, Buildkite.

Pass Pertama dari Konfigurasi dan Skrip Lingkungan

Ketika kami pertama kali bereksperimen dengan pengaturan Cypress, kami melakukannya di repo yang mencakup https://app.sendgrid.com, aplikasi web yang mencakup halaman fitur seperti Otentikasi Pengirim, Aktivitas Email, dan Validasi Email, dan kami pasti berbagi penemuan dan pembelajaran kami dengan tim di balik aplikasi web Kampanye Pemasaran kami, yang mencakup domain https://mc.sendgrid.com. Kami ingin menjalankan pengujian E2E kami terhadap lingkungan staging kami dan menggunakan antarmuka baris perintah dan opsi Cypress seperti --config atau --env untuk menyelesaikan kasus penggunaan kami.

Untuk menjalankan pengujian Cypress terhadap aplikasi web secara lokal pada misalnya http://127.0.0.1:8000 atau terhadap URL aplikasi staging yang diterapkan, kami menyesuaikan flag konfigurasi baseUrl dalam perintah dan menambahkan variabel lingkungan tambahan seperti testEnv untuk membantu memuat perlengkapan tertentu atau data pengujian khusus lingkungan dalam pengujian Cypress kami. Misalnya, kunci API yang digunakan, pengguna yang dibuat, dan sumber daya lainnya mungkin berbeda di seluruh lingkungan. Kami menggunakan testEnv untuk mengaktifkan perlengkapan tersebut atau menambahkan logika kondisional khusus jika beberapa fitur tidak didukung di lingkungan atau pengaturan pengujian berbeda dan kami akan mengakses lingkungan melalui panggilan seperti Cypress.env(“testEnv”) dalam spesifikasi kami.

Kami kemudian mengatur perintah kami cypress:open:* untuk mewakili pembukaan Cypress GUI bagi kami untuk memilih pengujian kami untuk dijalankan melalui UI ketika kami mengembangkan secara lokal dan cypress:run:* untuk menunjukkan menjalankan tes dalam mode tanpa kepala, yang lebih disesuaikan untuk dijalankan dalam wadah Docker selama CICD. Apa yang muncul setelah open atau run adalah lingkungan sehingga perintah kami akan mudah dibaca seperti npm run cypress:open:localhost:staging untuk membuka GUI dan menjalankan tes terhadap server dev Webpack lokal yang menunjuk ke staging API atau npm run cypress:run:staging untuk menjalankan pengujian dalam mode headless terhadap aplikasi staging dan API yang diterapkan. Skrip package.json Cypress keluar seperti ini:

Evolusi Konfigurasi dan Skrip Lingkungan

Di proyek lain, kami mengembangkan perintah dan konfigurasi Cypress untuk memanfaatkan beberapa logika Node di file cypress/plugins/index.js untuk memiliki file cypress.json dasar dan file konfigurasi terpisah yang akan dibaca berdasarkan variabel lingkungan yang disebut configFile untuk memuat file konfigurasi tertentu. File konfigurasi yang dimuat kemudian akan digabungkan dengan file dasar untuk akhirnya mengarah ke staging atau server backend tiruan.

Jika Anda bertanya-tanya lebih lanjut tentang server backend tiruan, kami mengembangkan server Express dengan titik akhir backend yang hanya mengembalikan berbagai respons dari data JSON statis dan kode status (yaitu 200, 4XX, 5XX) tergantung pada parameter kueri yang diteruskan dalam permintaan. Ini membuka blokir frontend untuk terus mengembangkan alur halaman dengan panggilan jaringan aktual ke server backend tiruan dengan respons yang meniru seperti apa tampilan API sebenarnya saat tersedia di masa mendatang. Kami juga dapat mensimulasikan berbagai tingkat keberhasilan dan respons kesalahan dengan mudah untuk status UI kami yang berbeda yang akan sulit untuk direproduksi dalam produksi, dan karena kami akan membuat panggilan jaringan deterministik, pengujian Cypress kami akan kurang terkelupas dalam menembakkan jaringan yang sama permintaan dan tanggapan setiap saat.

Kami memiliki file cypress.json dasar yang menyertakan properti bersama untuk batas waktu umum, ID proyek untuk dihubungkan dengan Layanan Dasbor Cypress yang akan kita bicarakan nanti, dan pengaturan lain seperti yang ditunjukkan di bawah ini:

Kami membuat folder config di folder cypress untuk menampung setiap file konfigurasi kami seperti localhostMock.json untuk menjalankan server pengembang Webpack lokal kami terhadap server API tiruan lokal atau staging.json untuk dijalankan terhadap aplikasi pementasan dan API yang diterapkan. File-file konfigurasi ini untuk di-diff dan digabungkan dengan konfigurasi dasar tampak seperti ini:

File konfigurasi CICD memiliki file JSON yang lebih sederhana karena kami perlu mengatur variabel lingkungan secara dinamis untuk memperhitungkan berbagai URL basis frontend layanan Docker dan host API server tiruan yang akan kami gali nanti.

Dalam file cypress/plugins/index.js kami, kami menambahkan logika untuk membaca variabel lingkungan yang disebut configFile set dari perintah Cypress yang pada akhirnya akan membaca file yang sesuai di folder config dan menggabungkannya dengan cypress.json dasar seperti di bawah ini:

Untuk menulis perintah Cypress yang masuk akal dengan variabel lingkungan yang disetel untuk kasus penggunaan kami, kami memanfaatkan Makefile yang menyerupai berikut ini:

Dengan perintah-perintah yang tertata rapi di Makefile, kita dapat dengan cepat melakukan hal-hal seperti make cypress_open_staging atau make cypress_run_staging dalam skrip `package.json` npm kita.

Sebelumnya, kami biasa menempatkan beberapa perintah dalam satu baris panjang yang akan sulit untuk diedit tanpa kesalahan. Untungnya, Makefile membantu menyebarkan banyak hal dengan lebih baik dengan interpolasi variabel lingkungan yang dapat dibaca ke dalam perintah Cypress di beberapa baris. Kita dapat dengan cepat mengatur atau mengekspor variabel lingkungan seperti configFile untuk memuat file konfigurasi lingkungan, BASE_URL untuk mengunjungi halaman kita, API_HOST untuk lingkungan backend yang berbeda, atau SPECS untuk menentukan pengujian mana yang akan dijalankan sebelum kita memulai perintah Makefile.

Kami juga menggunakan perintah Makefile untuk skrip npm panjang lainnya dan perintah Docker juga seperti membangun aset Webpack kami, menginstal dependensi, atau menjalankan perintah secara bersamaan dengan yang lain. Kami akhirnya akan menerjemahkan beberapa perintah Makefile ke dalam bagian skrip package.json , meskipun ini tidak diperlukan jika seseorang hanya ingin menggunakan Makefile, dan akan terlihat seperti berikut:

Kami sengaja mengabaikan banyak perintah Cypress CICD karena itu bukan perintah yang akan digunakan dalam pengembangan sehari-hari dan sebagai hasilnya membuat package.json lebih ramping. Yang terpenting, kita bisa melihat sekilas semua perintah Cypress yang terkait dengan server tiruan dan server pengembang Webpack lokal versus lingkungan pementasan dan mana yang "membuka" GUI daripada "berjalan" dalam mode tanpa kepala.

Langkah 3: Menerapkan tes E2E secara lokal

Saat kami mulai menerapkan pengujian E2E dengan Cypress, kami mereferensikan pengujian kami yang ada dari WebdriverIO dan STUI untuk mengonversi dan menambahkan pengujian yang lebih baru untuk fitur prioritas tinggi lainnya, mulai dari health check sederhana hingga alur happy path yang rumit. Menerjemahkan objek halaman yang ada dan menguji file dari WebdriverIO atau STUI ke objek halaman yang setara dan spesifikasi di Cypress terbukti sangat mudah. Ini benar-benar menghasilkan kode yang jauh lebih bersih daripada sebelumnya dengan elemen menunggu yang kurang eksplisit dan kemampuan rantai pernyataan yang lebih baik dan perintah Cypress lainnya.

Misalnya, langkah umum pengujian tetap sama dari perspektif pengguna akhir, sehingga pekerjaan konversi melibatkan pemetaan WebdriverIO atau STUI API ke Cypress API dengan cara berikut:

• Banyak perintah yang pada dasarnya muncul dan bekerja mirip dengan titik di mana kita hampir hanya mengganti $ atau browser dengan cy atau Cypress yaitu mengunjungi halaman melalui $(“.button”).click() ke cy.get(“.button”).click() , browser.url() ke cy.visit() , atau $(“.input”).setValue() ke cy.get(“.input”).type()
• Menggunakan $ atau $$ biasanya diubah menjadi cy.get(...) atau cy.contains(...) yaitu $$(“.multiple-elements-selector”) atau $(“.single-element-selector”) berubah menjadi cy.get(“.any-element-selector”) , cy.contains(“text”) , atau cy.contains(“.any-selector”)
• Menghapus $(“ $(“.selector”).waitForExist() $(“.selector”).waitForVisible(timeoutInMs) $(“.selector”).waitUntil(...) tangani percobaan ulang dan pengambilan elemen berulang kali dengan cy.get('.selector') dan cy.contains(textInElement) . Jika kita membutuhkan batas waktu yang lebih lama dari default, kita akan menggunakan cy.get('.selector', { timeout: longTimeoutInMs }) bersamaan dan kemudian setelah mengambil elemen, kita akan merangkai perintah tindakan berikutnya untuk melakukan sesuatu dengan elemen yaitu cy.get(“.selector”).click() .
• Perintah khusus dengan browser. addCommand('customCommand, () => {})` turned into `Cypress.Commands.add('customCommand', () => {}) dan melakukan `cy.customCommand()`
• Membuat permintaan jaringan untuk penyiapan atau pembongkaran melalui API menggunakan pustaka bernama node-fetch dan membungkusnya di browser.call(() => return fetch(...)) dan/atau browser.waitUntil(...) menyebabkan membuat permintaan HTTP di server Cypress Node melalui cy.request(endpoint) atau plugin khusus yang kami definisikan dan membuat panggilan seperti cy.task(taskToHitAPIOrService) .
• Sebelumnya ketika kami harus menunggu permintaan jaringan penting untuk mungkin selesai tanpa perubahan UI yang mencolok, kami terkadang harus menggunakan browser.pause(timeoutInMs) , tetapi dengan Cypress kami meningkatkannya dengan fungsionalitas penghentian jaringan dan dapat mendengarkan dan tunggu permintaan spesifik selesai dengan cy.server() , cy.route(“method”, “/endpoint/we/are/waiting/for).as(“endpoint”)`, and `cy.wait(“@endpoint”) sebelum memulai tindakan yang akan memicu permintaan.

Setelah menerjemahkan banyak sintaks dan perintah WebdriverIO ke perintah Cypress, kami membawa konsep yang sama memiliki objek halaman dasar untuk fungsionalitas bersama yang umum dan objek halaman yang diperluas untuk setiap halaman yang kami perlukan untuk pengujian. Berikut adalah contoh objek halaman dasar dengan fungsionalitas open() umum untuk dibagikan di semua halaman.

Objek halaman yang diperluas akan menambahkan getter untuk pemilih elemen, mengimplementasikan fungsionalitas open() dengan rute halamannya, dan menyediakan fungsionalitas pembantu apa pun seperti yang ditunjukkan di bawah ini.

Objek halaman diperpanjang kami yang sebenarnya juga menggunakan peta objek sederhana untuk mempertahankan semua elemen pemilih CSS kami di satu tempat yang akan kami sambungkan ke komponen React kami sebagai atribut data, referensi dalam pengujian unit, dan digunakan sebagai penyeleksi kami di objek halaman Cypress. Juga, kelas objek halaman kami kadang-kadang bervariasi dalam memanfaatkan konstruktor kelas jika mengatakan objek halaman digunakan kembali untuk sekelompok halaman yang tampak dan berfungsi serupa seperti halaman Penindasan kami dan kami akan memberikan argumen untuk mengubah rute atau properti tertentu.

Sebagai catatan tambahan, tim tidak perlu menggunakan objek halaman, tetapi kami menghargai konsistensi pola untuk menjaga fungsionalitas halaman dan referensi pemilih elemen DOM bersama dengan struktur objek kelas standar untuk berbagi fungsionalitas umum di semua halaman. Tim lain lebih suka membuat banyak file berbeda dengan sedikit fungsi utilitas dan tanpa menggunakan kelas ES6, tetapi hal penting yang harus diambil adalah menyediakan cara yang terorganisir dan dapat diprediksi untuk merangkum semuanya dan menulis tes untuk efisiensi dan pemeliharaan pengembang yang lebih baik.

Kami mengikuti strategi pengujian umum yang sama yang digunakan dengan pengujian WebdriverIO lama kami dengan mencoba menyiapkan pengujian sebanyak mungkin melalui API. Kami terutama ingin menghindari membangun status penyiapan kami melalui UI agar tidak menimbulkan kerapuhan dan waktu yang terbuang untuk bagian yang tidak ingin kami uji. Sebagian besar tes melibatkan strategi ini:

• Menyiapkan atau merobohkan melalui API – Jika kami perlu menguji pembuatan entitas melalui UI, kami akan memastikan untuk menghapus entitas terlebih dahulu melalui API. Terlepas dari bagaimana uji coba sebelumnya berakhir dengan sukses atau gagal, pengujian perlu disiapkan atau dihancurkan dengan benar melalui API untuk memastikan pengujian berperilaku secara konsisten dan dimulai dengan kondisi yang tepat.
• Masuk ke pengguna pengujian khusus melalui API – Kami membuat pengguna pengujian khusus per halaman atau bahkan per pengujian otomatisasi sehingga pengujian kami akan diisolasi dan tidak menginjak sumber daya satu sama lain saat dijalankan secara paralel. Kami membuat permintaan yang sama seperti halaman login kami melalui API dan menyimpan cookie sebelum pengujian dimulai sehingga kami dapat mengunjungi halaman yang diautentikasi secara langsung dan memulai langkah pengujian yang sebenarnya.
• Mengotomatiskan langkah-langkah dari perspektif pengguna akhir – Setelah masuk ke pengguna melalui API, kami mengunjungi halaman secara langsung dan mengotomatiskan langkah-langkah yang akan dilakukan pengguna akhir untuk menyelesaikan alur fitur dan memverifikasi bahwa pengguna melihat dan berinteraksi dengan hal yang benar sepanjang jalan.

Untuk menyetel ulang pengujian kembali ke keadaan semula yang diharapkan, kami akan masuk ke pengguna uji khusus melalui API dengan perintah cy.login global, menyetel cookie agar pengguna tetap masuk, membuat panggilan API diperlukan untuk mengembalikan pengguna ke status awal yang diinginkan melalui cy.request(“endpoint”) atau cy.task(“pluginAction”) , dan kunjungi halaman terotentikasi yang kami coba uji secara langsung. Kemudian, kami akan mengotomatiskan langkah-langkah untuk menyelesaikan aliran fitur pengguna seperti yang ditunjukkan pada tata letak pengujian di bawah ini.

Ingat perintah khusus yang kita bicarakan untuk masuk, cy.login() , dan keluar, cy.logout() ? Kami menerapkannya dengan mudah di Cypress dengan cara ini sehingga semua pengujian kami akan masuk ke pengguna melalui API dengan cara yang sama.

Selain itu, kami ingin mengotomatisasi dan memverifikasi alur kompleks tertentu yang melibatkan email yang sebelumnya tidak dapat kami lakukan dengan baik dengan WebdriverIO atau STUI. Beberapa contoh termasuk mengekspor Aktivitas Email ke CSV, melalui alur Kirim Ke Rekan Kerja untuk Otentikasi Pengirim, atau mengekspor hasil Validasi Email ke CSV. Cypress mencegah seseorang mengakses beberapa superdomain dalam satu pengujian, jadi bernavigasi ke klien email melalui UI yang tidak kami miliki tidak mudah dan bukan pilihan.

Kami malah mengembangkan plugin Cypress melalui cy.task(“pluginAction”) mereka untuk menggunakan beberapa perpustakaan di dalam server Cypress Node untuk terhubung ke klien/kotak masuk IMAP email uji seperti SquirrelMail untuk memeriksa email yang cocok di kotak masuk setelah meminta tindakan di UI dan untuk mengikuti tautan pengalihan dari email tersebut kembali ke domain aplikasi web kami untuk memverifikasi halaman unduhan tertentu yang muncul dan secara efektif menyelesaikan seluruh alur pelanggan. Kami menerapkan plugin yang akan menunggu email tiba di kotak masuk SquirrelMail dengan baris subjek tertentu, menghapus email, mengirim email, memicu acara email, polling layanan backend, dan melakukan penyiapan dan pembongkaran yang jauh lebih berguna melalui API untuk pengujian kami untuk digunakan.

Untuk memberikan lebih banyak wawasan tentang apa yang sebenarnya kami uji dengan Cypress, kami membahas sejumlah besar kasus bernilai tinggi seperti ini:

• Pemeriksaan kesehatan untuk semua halaman kami alias tur aplikasi – Kami ingin memastikan halaman yang dimuat dengan beberapa konten menyebabkan terkadang layanan backend tertentu atau hosting frontend akan down. Kami juga merekomendasikan untuk melakukan tes ini terlebih dahulu untuk membangun memori otot mental dalam membangun objek halaman dengan selektor dan fungsi pembantu dan untuk mendapatkan tes kerja yang cepat berjalan terhadap lingkungan.
• Operasi CRUD pada halaman – Kami akan selalu menyetel ulang pengujian yang sesuai melalui API dan kemudian menguji secara khusus pembuatan, membaca, memperbarui, atau menghapus di UI. Misalnya, jika kami menguji kemampuan untuk membuat autentikasi domain melalui UI, terlepas dari bagaimana uji coba terakhir berakhir, kami perlu memastikan bahwa domain yang akan kami buat melalui UI pada awalnya dihapus melalui API sebelum melanjutkan dengan langkah-langkah UI otomatis untuk membuat domain dan menghindari tabrakan. Jika kami menguji kemampuan untuk menghapus penindasan melalui UI, kami memastikan untuk membuat penindasan melalui API terlebih dahulu dan kemudian melanjutkan dengan langkah-langkahnya.
• Menguji filter pencarian pada halaman – Kami menguji pengaturan sekelompok filter pencarian lanjutan dengan Aktivitas Email dan mengunjungi halaman dengan parameter kueri untuk memastikan filter terisi secara otomatis. Kami juga menambahkan data melalui API untuk Validasi Email dan sekali lagi memulai filter pencarian yang berbeda dan memvalidasi tabel yang cocok dengan filter pencarian di halaman itu.
• Akses pengguna yang berbeda – Di Twilio SendGrid, kami memiliki akun induk yang dapat memiliki rekan satu tim dengan berbagai cakupan atau izin akses atau subpengguna di bawahnya yang juga memiliki berbagai tingkat akses dan berperilaku agak mirip dengan akun induk. Rekan tim dengan akses hanya baca versus admin untuk halaman dan subpengguna tertentu akan melihat atau tidak melihat hal-hal tertentu pada halaman dan itu memudahkan untuk mengotomatiskan masuk ke jenis pengguna tersebut dan memeriksa apa yang mereka lihat atau tidak lihat dalam tes Cypress.
• Paket pengguna yang berbeda – Pengguna kami juga dapat bervariasi dalam jenis paket gratis hingga berbayar seperti Essentials, Pro, dan Premier dan paket tersebut juga dapat melihat atau tidak melihat hal-hal tertentu pada halaman. Kami akan masuk ke pengguna dengan paket yang berbeda dan memverifikasi dengan cepat fitur, salinan, atau halaman yang dapat diakses pengguna dalam tes Cypress.

Langkah 4: Dockerizing tes

Saat menjalankan setiap langkah pipeline Buildkite pada mesin AWS baru di cloud, kami tidak bisa begitu saja memanggil npm run cypress:run:staging karena mesin tersebut tidak memiliki Node, browser, kode aplikasi kami, atau dependensi lainnya untuk benar-benar menjalankan Cypress tes. Saat kami menyiapkan WebdriverIO sebelumnya, kami perlu merakit tiga layanan terpisah dalam file Docker Compose agar layanan Selenium, Chrome, dan kode aplikasi yang tepat beroperasi bersama untuk menjalankan pengujian.

Dengan Cypress, itu jauh lebih mudah karena kami hanya memerlukan gambar Docker basis Cypress, cypress/base , untuk mengatur lingkungan di Dockerfile dan hanya satu layanan dalam file docker-compose.yml dengan kode aplikasi kami untuk menjalankan Cypress tes. Kami akan membahas satu cara untuk melakukannya karena ada gambar Cypress Docker lain untuk digunakan dan cara lain untuk mengatur tes Cypress di Docker. Kami mendorong Anda untuk melihat dokumentasi Cypress untuk alternatif

Untuk memunculkan layanan dengan semua aplikasi kami dan kode pengujian yang diperlukan untuk menjalankan tes Cypress, kami membuat Dockerfile bernama Dockerfile.cypress dan menginstal semua node_modules dan menyalin kode ke direktori kerja gambar di lingkungan Node. Ini akan digunakan oleh layanan cypress Docker Compose kami dan kami mencapai pengaturan Dockerfile dengan cara berikut:

Dengan Dockerfile.cypress ini, kita dapat mengintegrasikan Cypress untuk menjalankan spesifikasi yang dipilih terhadap API lingkungan tertentu dan menerapkan aplikasi melalui satu layanan Docker Compose yang disebut cypress . Yang harus kami lakukan hanyalah menginterpolasi beberapa variabel lingkungan seperti SPECS dan BASE_URL untuk menjalankan tes Cypress yang dipilih terhadap URL dasar tertentu melalui perintah npm run cypress:run:cicd:staging yang terlihat seperti ini, ”cypress:run:cicd:staging”: “cypress run --record --key --config baseUrl=$BASE_URL --env testEnv=staging” .

Variabel lingkungan ini akan disetel melalui file pengaturan/konfigurasi pipeline Buildkite atau diekspor secara dinamis saat memicu pengujian Cypress untuk dijalankan dari pipeline penerapan kami. Contoh file docker-compose.cypress.yml terlihat mirip dengan ini:

Ada juga beberapa hal lain yang perlu diperhatikan. Misalnya, Anda dapat melihat variabel lingkungan VERSION yang memungkinkan kami untuk mereferensikan gambar Docker yang diberi tag tertentu. Kami akan mendemonstrasikan nanti bagaimana kami memberi tag pada gambar Docker dan kemudian menarik gambar Docker yang sama agar build tersebut dapat dijalankan dengan kode yang benar untuk pengujian Cypress.

Selain itu, Anda juga akan melihat BUILDKITE_BUILD_ID yang dilewati, yang datang secara gratis bersama dengan variabel lingkungan Buildkite lainnya untuk setiap build yang kita mulai, dan flag ci-build-id . Ini mengaktifkan fitur paralelisasi Cypress dan ketika kami menetapkan sejumlah mesin yang dialokasikan untuk pengujian Cypress, ia akan secara otomatis mengetahui cara memutar mesin tersebut dan memisahkan pengujian kami untuk dijalankan di semua node mesin tersebut untuk mengoptimalkan dan mempercepat pengujian kami menjalankan kali.

Kami akhirnya juga memanfaatkan pemasangan volume dan fitur artefak Buildkite. Kami mengunggah video dan tangkapan layar agar dapat diakses langsung melalui tab “Artefak” UI Buildkite jika kami kehabisan rekaman uji berbayar yang dialokasikan untuk bulan tersebut atau entah bagaimana tidak dapat mengakses Layanan Dasbor. Setiap kali seseorang menjalankan perintah "jalankan" Cypress dalam mode tanpa kepala, ada output di folder cypress/videos dan cypress/screenshots untuk ditinjau secara lokal dan kami cukup memasang folder tersebut dan mengunggahnya ke Buildkite untuk kami sebagai fail-safe.

Langkah 5: Mengintegrasikan dengan CICD

Setelah pengujian Cypress berhasil dijalankan dalam wadah Docker terhadap lingkungan yang berbeda, kami mulai berintegrasi dengan Buildkite, penyedia CICD kami. Buildkite menyediakan cara untuk mengeksekusi langkah-langkah dalam file .yml pada mesin AWS kami dengan skrip Bash dan variabel lingkungan yang diatur baik dalam kode atau melalui pengaturan pipeline Buildkite repo di UI web. Buildkite juga memungkinkan kami untuk memicu pipeline pengujian ini dari pipeline penerapan utama kami dengan variabel lingkungan yang diekspor dan kami akan menggunakan kembali langkah pengujian ini untuk pipeline pengujian terisolasi lainnya yang akan berjalan sesuai jadwal untuk dipantau dan dilihat oleh QA kami.

Pada tingkat tinggi, pipeline Buildkite pengujian kami untuk Cypress dan juga pipeline WebdriverIO kami sebelumnya berbagi langkah serupa berikut:

• Siapkan gambar Docker . Bangun, beri tag, dan dorong gambar Docker yang diperlukan untuk pengujian ke registri sehingga kami dapat menariknya ke bawah di langkah selanjutnya.
• Jalankan tes berdasarkan konfigurasi variabel lingkungan . Tarik gambar Docker yang diberi tag untuk build tertentu dan jalankan perintah yang tepat terhadap lingkungan yang diterapkan untuk menjalankan rangkaian pengujian yang dipilih dari variabel lingkungan yang ditetapkan.

Berikut adalah contoh file pipeline.cypress.yml yang mendemonstrasikan pengaturan image Docker di langkah “Build Cypress Docker Image” dan menjalankan pengujian di langkah “Run Cypress test”:

Satu hal yang perlu diperhatikan adalah langkah pertama, “Build Cypress Docker Image”, dan cara menyiapkan image Docker untuk pengujian. Itu menggunakan perintah build Docker Compose untuk membangun layanan cypress dengan semua kode pengujian aplikasi dan menandainya dengan variabel lingkungan latest dan ${VERSION} sehingga kami akhirnya dapat menarik gambar yang sama dengan tag yang tepat untuk build ini dalam a langkah masa depan. Setiap langkah dapat dijalankan pada mesin yang berbeda di cloud AWS di suatu tempat, sehingga tag secara unik mengidentifikasi gambar untuk menjalankan Buildkite tertentu. Setelah menandai gambar, kami mendorong gambar terbaru dan versi yang diberi tag ke registri Docker pribadi kami untuk digunakan kembali.

Pada langkah "Jalankan tes Cypress", kami menarik gambar yang kami buat, beri tag, dan dorong pada langkah pertama dan memulai layanan Cypress untuk menjalankan tes. Berdasarkan variabel lingkungan seperti SPECS dan BASE_URL , kami akan menjalankan file pengujian khusus terhadap lingkungan aplikasi tertentu yang diterapkan untuk build Buildkite khusus ini. Variabel lingkungan ini akan ditetapkan melalui pengaturan pipa Buildkite atau akan dipicu secara dinamis dari skrip Bash yang akan mengurai bidang pilih Buildkite untuk menentukan rangkaian pengujian mana yang dijalankan dan terhadap lingkungan mana.

Saat kami memilih pengujian mana yang akan dijalankan selama jalur penerapan Buildkite CICD kami dan memicu jalur pengujian terpicu khusus dengan variabel lingkungan tertentu yang diekspor, kami mengikuti langkah-langkah dalam file pipeline.cypress.yml untuk mewujudkannya. Contoh memicu pengujian setelah menerapkan beberapa kode baru ke lingkungan cabang fitur dari pipa penerapan terlihat seperti ini:

Tes yang dipicu akan berjalan di saluran terpisah dan setelah mengikuti tautan "Build #639", itu akan membawa kita ke langkah-langkah build untuk menjalankan tes yang dipicu seperti di bawah ini:

Menggunakan kembali file pipeline.cypress.yml Cypress Buildkite khusus kami yang berjalan sesuai jadwal, kami memiliki build seperti yang menjalankan "P1", tes E2E prioritas tertinggi kami, seperti yang ditunjukkan pada foto di bawah ini:

Yang harus kita lakukan adalah mengatur variabel lingkungan yang tepat untuk hal-hal seperti spesifikasi mana yang akan dijalankan dan lingkungan backend mana yang harus dicapai dalam pengaturan pipa Buildkite. Kemudian, kita dapat mengonfigurasi build terjadwal Cron, yang juga ada dalam pengaturan pipeline, untuk memulai setiap beberapa jam dan kita siap melakukannya. We would then create many other separate pipelines for specific feature pages as needed to run on a schedule in a similar way and we would only vary the Cron schedule and environment variables while once again uploading the same `pipeline.cypress.yml` file to execute.

In each of those “Run Cypress tests” steps, we can see the console output with a link to the recorded test run in the paid Dashboard Service, the central place to manage your team's test recordings, billing, and other Cypress stats. Following the Dashboard Service link would take us to a results view for developers and QAs to take a look at the console output, screenshots, video recordings, and other metadata if required such as this:

Step 6: Comparing Cypress vs. WebdriverIO/STUI

After diving into our own custom Ruby Selenium solution in STUI, WebdriverIO, and finally Cypress tests, we recorded our tradeoffs between Cypress and Selenium wrapper solutions.

kelebihan

• It's not another Selenium wrapper – Our previous solutions came with a lot of Selenium quirks, bugs, and crashes to work around and resolve, whereas Cypress arrived without the same baggage and troubles to deal with in allowing us full access to the browser.
• More resilient selectors – We no longer had to explicitly wait for everything like in WebdriverIO with all the $(.selector).waitForVisible() calls and now rely on cy.get(...) and c y.contains(...) commands with their default timeout. It will automatically keep on retrying to retrieve the DOM elements and if the test demanded a longer timeout, it is also configurable per command. With less worrying about the waiting logic, our tests became way more readable and easier to chain.
• Vastly improved developer experience – Cypress provides a large toolkit with better and more extensive documentation for assertions, commands, and setup. We loved the options of using the Cypress GUI, running in headless mode, executing in the command-line, and chaining more intuitive Cypress commands.
• Significantly better developer efficiency and debugging – When running the Cypress GUI, one has access to all of the browser console to see some helpful output, time travel debug and pause at certain commands in the command log to see before and after screenshots, inspect the DOM with the selector playground, and discern right away at which command the test failed. In WebdriverIO or STUI we struggled with observing the tests run over and over in a browser and then the console errors would not point us toward and would sometimes even lead us astray from where the test really failed in the code. When we opted to run the Cypress tests in headless mode, we got console errors, screenshots, and video recordings. With WebdriverIO we only had some screenshots and confusing console errors. These benefits resulted in us cranking out E2E tests much faster and with less overall time spent wondering why things went wrong. We recorded it took less developers and often around 2 to 3 times less days to write the same level of complicated tests with Cypress than with WebdriverIO or STUI.
• Network stubbing and mocking – With WebdriverIO or STUI, there was no such thing as network stubbing or mocking in comparison to Cypress. Now we can have endpoints return certain values or we can wait for certain endpoints to finish through cy.server() and cy.route() .
• Less time to set up locally – With WebdriverIO or STUI, there was a lot of time spent up front researching which reporters, test runners, assertions, and services to use, but with Cypress, it came bundled with everything and started working after just doing an npm install cypress.
• Less time to set up with Docker – There are a bunch of ways to set up WebdriverIO with Selenium, browser, and application images that took us considerably more time and frustration to figure out in comparison to Cypress's Docker images to use right out of the gate.
• Parallelization with various CICD providers – We were able to configure our Buildkite pipelines to spin up a certain number of AWS machines to run our Cypress tests in parallel to dramatically speed up the overall test run time and uncover any flakiness in tests using the same resources. The Dashboard Service would also recommend to us the optimal number of machines to spin up in parallel for the best test run times.
• Paid Dashboard Service – When we run our Cypress tests in a Docker container in a Buildkite pipeline during CICD, our tests are recorded and stored for us to look at within the past month through a paid Dashboard Service. We have a parent organization for billing and separate projects for each frontend application to check out console output, screenshots, and recordings of all of our test runs.
• Tests are way more consistent and maintainable – Tests passed way more consistently with Cypress in comparison to WebdriverIO and STUI where the tests kept on failing so much to the point where they were often ignored. Cypress tests failing more often signaled actual issues and bugs to look into or suggested better ways to refactor our tests to be less flaky. With WebdriverIO and STUI, we wasted a lot more time in maintaining those tests to be somewhat useful, whereas with Cypress, we would every now and then adjust the tests in response to changes in the backend services or minor changes in the UI.
• Tests are faster – Builds passed way more consistently and overall test run times would be around 2 to 3 times faster when run serially without parallelization. We used to have overall test runs that would take hours with STUI and around 40 minutes with WebdriverIO, but now with way more tests and with the help of parallelization across many machine nodes, we can run over 200 tests in under 5 minutes .
• Room to grow with added features in the future – With a steady open-source presence and dedicated Cypress team working towards releasing way more features and improvements to the Cypress infrastructure, we viewed Cypress as a safer bet to invest in rather than STUI, which would require us to engineer and solve a lot of the headaches ourselves, and WebdriverIO, which appeared to feel more stagnant in new features added but with the same baggage as other Selenium wrappers.

Kontra

• Lack of cross-browser support – As of this writing, we can only run our tests against Chrome. With WebdriverIO, we could run tests against Chrome, Firefox, Safari, and Opera. STUI also provided some cross-browser testing, though in a much limited form since we created a custom in-house solution
• Cannot integrate with some third-party services – With WebdriverIO, we had the option to integrate with services like BrowserStack and Sauce Labs for cross-browser and device testing. However, with Cypress there are no such third-party integrations but there are some plugins with services like Applitools for visual regression testing available. STUI, on the other hand, also had some small integrations with TestRail , but as a compromise, we log out the TestRail links in our Cypress tests so we can refer back to them if we needed to.
• Requires workarounds to test with iframes – There are some issues around handling iframes with Cypress. We ended up creating a global Cypress command to wrap how to deal with retrieving an iframe's contents as there is no specific API to deal with iframes like how WebdriverIO does.

To summarize our STUI, WebdriverIO, and Cypress comparison, we analyzed the overall developer experience (related to tools, writing tests, debugging, API, documentation, etc.), test run times, test passing rates, and maintenance as displayed in this table:

Following our analysis of the pros and cons of Cypress versus our previous solutions, it was pretty clear Cypress would be our best bet to accomplish our goal of writing fast, valuable, maintainable, and debuggable E2E tests we could integrate with CICD.

Though Cypress lacked features such as cross-browser testing and other integrations with third-party services that we could have had with STUI or WebdriverIO, we most importantly need tests that work more often than not and with the right tools to confidently fix broken ones. If we ever needed cross-browser testing or other integrations we could always still circle back and use our knowledge from our trials and experiences with WebdriverIO and STUI to still run a subset of tests with those frameworks.

We finally presented our findings to the rest of the frontend organization, engineering management, architects, and product. Upon demoing the Cypress test tools and showcasing our results between WebdriverIO/STUI and Cypress, we eventually received approval to standardize and adopt Cypress as our E2E testing library of choice for our frontend teams.

Step 7: Scaling to Other Frontend Teams

After successfully proving that using Cypress was the way to go for our use cases, we then focused on scaling it across all of our frontend teams' repos. We shared lessons learned and patterns of how to get up and running, how to write consistent, maintainable Cypress tests, and of how to hook those tests up during CICD or in scheduled Cypress Buildkite pipelines.

To promote greater visibility of test runs and gain access to a private monthly history of recordings, we established our own organization to be under one billing method to pay for the Dashboard Service with a certain recorded test run limit and maximum number of users in the organization to suit our needs.

Once we set up an umbrella organization, we invited developers and QAs from different frontend teams and each team would install Cypress, open up the Cypress GUI, and inspect the “Runs” and “Settings” tab to get the “Project ID” to place in their `cypress.json` configuration and “Record Key” to provide in their command options to start recording tests to the Dashboard Service. Finally, upon successfully setting up the project and recording tests to the Dashboard Service for the first time, logging into the Dashboard Service would show that team's repo under the “Projects” tab like this:

When we clicked a project like “mako”, we then had access to all of the test runs for that team's repo with quick access to console output, screenshots, and video recordings per test run upon clicking each row as shown below:

For more insights into our integration, we set up many separate dedicated test pipelines to run specific, crucial page tests on a schedule like say every couple hours to once per day. We also added functionality in our main Buildkite CICD deploy pipeline to select and trigger some tests against our feature branch environment and staging environment.

Seperti yang bisa diduga, ini dengan cepat meledak melalui uji coba tercatat kami yang dialokasikan untuk bulan itu, terutama karena ada beberapa tim yang berkontribusi dan memicu tes dengan berbagai cara. Dari pengalaman, kami merekomendasikan untuk memperhatikan berapa banyak tes yang berjalan sesuai jadwal, seberapa sering tes tersebut dijalankan, dan tes apa yang dijalankan selama CICD. Mungkin ada beberapa uji coba yang berlebihan dan area lain yang lebih hemat seperti memutar kembali frekuensi uji coba terjadwal atau mungkin menghilangkan sebagian untuk memicu tes hanya selama CICD.

Aturan hemat yang sama berlaku untuk menambahkan pengguna karena kami menekankan menyediakan akses hanya ke pengembang dan QA di tim frontend yang akan menggunakan Layanan Dasbor secara berlebihan daripada manajemen tingkat atas dan orang lain di luar tim tersebut untuk mengisi tempat terbatas tersebut.

Apa yang kami nantikan dengan Cypress

Seperti yang kami sebutkan sebelumnya, Cypress menunjukkan banyak janji dan potensi pertumbuhan di komunitas open source dan dengan tim khusus yang bertanggung jawab untuk memberikan lebih banyak fitur bermanfaat untuk kami gunakan dengan pengujian E2E kami. Banyak kelemahan yang kami soroti saat ini sedang ditangani dan kami menantikan hal-hal seperti:

• Dukungan lintas-browser – Ini adalah dukungan besar karena banyak dorongan balik dari kami yang mengadopsi Cypress berasal dari penggunaan hanya Chrome dibandingkan dengan solusi berbasis Selenium, yang mendukung browser seperti Firefox, Chrome, dan Safari. Untungnya, pengujian yang lebih andal, dapat dipelihara, dan dapat di-debug menang untuk organisasi kami dan kami berharap dapat meningkatkan rangkaian pengujian kami dengan lebih banyak pengujian lintas-browser di masa mendatang ketika tim Cypress merilis dukungan lintas-browser tersebut.
• Penulisan ulang lapisan jaringan – Ini juga merupakan masalah besar karena kami cenderung menggunakan Fetch API secara besar-besaran di area React kami yang lebih baru dan di area aplikasi Backbone/Marionette yang lebih lama, kami masih menggunakan jQuery AJAX dan panggilan berbasis XHR normal. Kami dapat dengan mudah mematikan atau mendengarkan permintaan di area XHR, tetapi harus melakukan beberapa solusi peretasan dengan mengambil polyfill untuk mencapai efek yang sama. Penulisan ulang lapisan jaringan seharusnya membantu meringankan rasa sakit itu.
• Peningkatan bertahap pada Layanan Dasbor – Kami telah melihat beberapa perubahan UI baru pada Layanan Dasbor baru-baru ini dan kami berharap untuk terus melihatnya berkembang dengan lebih banyak visualisasi stat dan perincian data yang berguna. Kami juga sering menggunakan fitur paralelisasi dan sering memeriksa rekaman pengujian kami yang gagal di Layanan Dasbor, jadi setiap peningkatan berulang pada tata letak dan/atau fitur akan menyenangkan untuk dilihat.

Mengadopsi Cypress ke Masa Depan

Untuk organisasi kami, kami menghargai efisiensi pengembang, debugging, dan stabilitas pengujian Cypress saat dijalankan di bawah browser Chrome. Kami mencapai pengujian yang konsisten dan berharga dengan lebih sedikit perawatan di jalan dan dengan banyak alat untuk mengembangkan pengujian baru dan memperbaiki yang sudah ada.

Secara keseluruhan, dokumentasi, API, dan alat yang kami miliki jauh melebihi kekurangannya. Setelah mengalami Cypress GUI dan Layanan Dashboard berbayar, kami pasti tidak ingin kembali ke WebdriverIO atau solusi Ruby Selenium kustom kami.

Kami menghubungkan pengujian kami dengan Buildkite dan mencapai tujuan kami menyediakan cara untuk menulis pengujian otomatisasi E2E yang konsisten, dapat di-debug, dipelihara, dan berharga untuk aplikasi frontend kami untuk diintegrasikan dengan CICD . Kami membuktikan dengan bukti kepada tim frontend lainnya, petinggi teknik, dan pemilik produk tentang manfaat mengadopsi Cypress dan menghapus WebdriverIO dan STUI.

Ratusan tes nanti di seluruh tim frontend di Twilio SendGrid dan kami menemukan banyak bug di lingkungan pementasan kami dan dapat dengan cepat memperbaiki tes yang tidak stabil di pihak kami dengan lebih percaya diri daripada sebelumnya. Pengembang dan QA tidak lagi takut memikirkan menulis tes E2E tetapi sekarang berharap untuk menulisnya untuk setiap fitur baru yang kami rilis atau untuk setiap fitur lama yang dapat menggunakan lebih banyak cakupan.