1.000 Kaki Ikhtisar Menulis Tes Cypress #frontend@twiliosendgrid

Di Twilio SendGrid, kami telah menulis ratusan pengujian Cypress end-to-end (E2E) dan terus menulis lebih banyak lagi saat fitur baru dirilis di berbagai aplikasi web dan tim. Pengujian ini mencakup seluruh tumpukan, memverifikasi bahwa kasus penggunaan paling umum yang akan dilalui pelanggan masih berfungsi setelah mendorong perubahan kode baru dalam aplikasi kami.

Jika Anda ingin mengambil langkah mundur terlebih dahulu dan membaca lebih lanjut tentang cara berpikir tentang pengujian E2E secara umum, silakan lihat posting blog ini dan kembali lagi setelah Anda siap. Postingan blog ini tidak mengharuskan Anda menjadi ahli dalam pengujian E2E, tetapi ini membantu untuk memahami kerangka berpikir yang benar karena Anda akan melihat mengapa kami melakukan sesuatu dengan cara tertentu dalam pengujian kami. Jika Anda mencari tutorial selangkah demi selangkah yang memperkenalkan Anda pada pengujian Cypress, kami sarankan untuk memeriksa dokumen Cypress . Dalam posting blog ini, kami berasumsi Anda mungkin telah melihat atau menulis banyak tes Cypress sebelumnya dan penasaran untuk melihat bagaimana orang lain menulis tes Cypress untuk aplikasi mereka sendiri.

Setelah menulis banyak tes Cypress, Anda akan mulai memperhatikan diri Anda menggunakan fungsi, pernyataan, dan pola Cypress yang serupa untuk mencapai apa yang Anda butuhkan. Kami akan menunjukkan kepada Anda bagian dan strategi paling umum yang telah kami gunakan atau lakukan sebelumnya dengan Cypress untuk menulis tes terhadap lingkungan terpisah seperti dev atau staging. Kami berharap ikhtisar 1.000 kaki tentang cara kami menulis tes Cypress ini memberi Anda ide untuk dibandingkan dengan milik Anda sendiri dan membantu Anda meningkatkan cara Anda mendekati tes Cypress.

Garis besar:

1. Roundup Cypress API
2. Berinteraksi dengan elemen
3. Menegaskan pada elemen
4. Berurusan dengan API dan layanan
5. Membuat permintaan HTTP dengan cy.request(…)
6. Membuat plugin yang dapat digunakan kembali dengan cy.task()
7. Mengejek permintaan jaringan dengan cy.server() dan cy.route()
8. Perintah khusus
9. Tentang objek halaman
10. Memilih untuk tidak menjalankan kode sisi klien dengan window.Cypress checks
11. Berurusan dengan iframe
12. Standarisasi di seluruh lingkungan pengujian

Roundup Cypress API

Mari kita mulai dengan menelusuri bagian-bagian yang paling sering kita gunakan dengan Cypress API.

Memilih elemen

Ada banyak cara untuk memilih elemen DOM, tetapi Anda dapat menyelesaikan sebagian besar dari apa yang perlu Anda lakukan melalui perintah Cypress ini dan Anda biasanya dapat mengaitkan lebih banyak tindakan dan pernyataan setelah ini.

• Mendapatkan elemen berdasarkan beberapa pemilih CSS dengan cy.get(“[data-hook='someSelector']”) atau cy.find(“.selector”) .
• Memilih elemen berdasarkan beberapa teks seperti cy.contains(“someText”) atau mendapatkan elemen dengan pemilih tertentu yang berisi beberapa teks seperti cy.contains(“.selector”, “someText”) .
• Membuat elemen induk terlihat "di dalam", jadi semua kueri Anda di masa mendatang akan dicakupkan ke anak induk seperti cy.get(“.selector”).within(() => { cy.get(“.child”) }) .
• Menemukan daftar elemen dan melihat melalui “setiap” satu untuk melakukan lebih banyak kueri dan pernyataan seperti cy.get(“tr”).each(($tableRow) => { cy.wrap($tableRow).find('td').eq(1).should(“contain”, “someText” }) .
• Terkadang, elemen mungkin tidak terlihat di halaman, jadi Anda harus menggulir elemen ke tampilan terlebih dahulu seperti cy.get(“.buttonFarBelow”).scrollIntoView() .
• Terkadang Anda memerlukan batas waktu yang lebih lama daripada batas waktu perintah default, sehingga Anda dapat menambahkan { timeout: timeoutInMs } opsional seperti cy.get(“.someElement”, { timeout: 10000 }) .

Berinteraksi dengan elemen

Ini adalah interaksi yang paling sering digunakan yang ditemukan di seluruh pengujian Cypress kami. Terkadang, Anda harus memasukkan properti { force: true } dalam panggilan fungsi tersebut untuk melewati beberapa pemeriksaan dengan elemen. Hal ini sering terjadi saat elemen tercakup dalam beberapa cara atau berasal dari perpustakaan eksternal yang Anda tidak memiliki banyak kendali dalam hal cara merender elemen.

• Kita perlu mengklik banyak hal seperti tombol di modals, tabel, dan sejenisnya, jadi kita melakukan hal-hal seperti cy.get(“.button”).click() .
• Formulir ada di mana-mana di aplikasi web kami untuk mengisi detail pengguna dan bidang data lainnya. Kami mengetikkan input tersebut dengan cy.get(“input”).type(“somekeyboardtyping”) dan kami mungkin perlu menghapus beberapa nilai default input dengan menghapusnya terlebih dahulu seperti cy.get(“input”).clear().type(“somenewinput”) . Ada juga cara keren untuk mengetik tombol lain seperti {enter} untuk tombol Enter saat Anda melakukan cy.get(“input”).type(“text{enter}”) .
• Kita dapat berinteraksi dengan opsi pilih seperti cy.get(“select”).select(“value”) dan kotak centang seperti cy.get(“.checkbox”).check() .

Menegaskan pada elemen

Ini adalah pernyataan khas yang dapat Anda gunakan dalam pengujian Cypress Anda untuk menentukan apakah ada hal-hal yang ada di halaman dengan konten yang tepat.

• Untuk memeriksa apakah sesuatu muncul atau tidak pada halaman, Anda dapat beralih antara cy.get(“.selector”).should(“be.visible”) dan cy.get(“.selector”).should(“not.be.visible”) .
• Untuk menentukan apakah elemen DOM ada di suatu tempat di markup dan jika Anda tidak perlu peduli apakah elemen tersebut terlihat, Anda dapat menggunakan cy.get(“.element”).should(“exist”) atau cy.get(“.element”).should(“not.exist”) .
• Untuk melihat apakah suatu elemen berisi atau tidak mengandung beberapa teks, Anda dapat memilih antara cy.get(“button”).should(“contain”, “someText”) dan cy.get(“button”).should(“not.contain”, “someText”) .
• Untuk memverifikasi input atau tombol dinonaktifkan atau diaktifkan, Anda dapat menegaskan seperti ini: cy.get(“button”).should(“be.disabled”) .
• Untuk menegaskan apakah sesuatu dicentang, Anda dapat menguji seperti, cy.get(“.checkbox”).should(“be.checked”) .
• Anda biasanya dapat mengandalkan pemeriksaan teks dan visibilitas yang lebih nyata, tetapi terkadang Anda harus mengandalkan pemeriksaan kelas seperti cy.get(“element”).should(“have.class”, “class-name”) . Ada cara serupa lainnya untuk menguji atribut juga dengan .should(“have.attr”, “attribute”) .
• Seringkali berguna bagi Anda untuk menggabungkan pernyataan bersama seperti, cy.get(“div”).should(“be.visible”).and(“contain”, “text”) .

Berurusan dengan API dan layanan

Saat menangani API dan layanan Anda sendiri yang terkait dengan email, Anda dapat menggunakan cy.request(...) untuk membuat permintaan HTTP ke titik akhir backend Anda dengan header auth. Alternatif lain adalah Anda dapat membuat cy.task(...) yang dapat dipanggil dari file spesifikasi apa pun untuk mencakup fungsionalitas lain yang paling baik ditangani di server Node dengan pustaka lain seperti menghubungkan ke kotak masuk email dan menemukan email yang cocok atau memiliki kontrol lebih besar atas respons dan polling panggilan API tertentu sebelum mengembalikan beberapa nilai untuk digunakan pengujian.

Membuat permintaan HTTP dengan cy.request(…)

Anda dapat menggunakan cy.request() untuk membuat permintaan HTTP ke API backend Anda untuk menyiapkan atau menghapus data sebelum kasus pengujian Anda berjalan. Anda biasanya meneruskan URL titik akhir, metode HTTP seperti “GET” atau “POST”, header, dan terkadang badan permintaan untuk dikirim ke API backend. Anda kemudian dapat menghubungkan ini dengan .then((response) => { }) untuk mendapatkan akses ke respons jaringan melalui properti seperti "status" dan "body". Contoh membuat panggilan cy.request() ditunjukkan di sini.

Terkadang, Anda mungkin tidak peduli apakah cy.request(...) akan gagal dengan kode status 4xx atau 5xx selama pembersihan sebelum pengujian berjalan. Satu skenario di mana Anda dapat memilih untuk mengabaikan kode status yang gagal adalah saat pengujian Anda membuat permintaan GET untuk memeriksa apakah item masih ada dan sudah dihapus. Item mungkin sudah dibersihkan dan permintaan GET akan gagal dengan kode status 404 tidak ditemukan. Dalam hal ini, Anda akan menetapkan opsi lain dari failOnStatusCode: false sehingga pengujian Cypress Anda tidak gagal bahkan sebelum menjalankan langkah pengujian.

Membuat plugin yang dapat digunakan kembali dengan cy.task()

Ketika kami ingin memiliki lebih banyak fleksibilitas dan kontrol atas fungsi yang dapat digunakan kembali untuk berbicara dengan layanan lain seperti penyedia kotak masuk email melalui server Node (kami akan membahas contoh ini di posting blog selanjutnya), kami ingin menyediakan fungsionalitas ekstra kami sendiri dan tanggapan khusus untuk panggilan API agar kami dapat menghubungkan dan menerapkan dalam pengujian Cypress kami. Atau, kami suka menjalankan beberapa kode lain di server Node—kami sering membuat plugin cy.task() untuknya. Kami membuat fungsi plugin dalam file modul dan mengimpornya di plugins/index.ts tempat kami mendefinisikan plugin tugas dengan argumen yang kami butuhkan untuk menjalankan fungsi seperti yang ditunjukkan di bawah ini.

Plugin ini dapat dipanggil dengan cy.task(“pluginName”, { ...args }) di mana saja di file spesifikasi Anda dan Anda dapat mengharapkan fungsionalitas yang sama terjadi. Sedangkan, jika Anda menggunakan cy.request() , Anda memiliki lebih sedikit kegunaan kembali kecuali Anda membungkus panggilan itu sendiri dalam objek halaman atau file pembantu untuk diimpor ke mana-mana.

Satu peringatan lainnya adalah karena kode tugas plugin dimaksudkan untuk dijalankan di server Node, Anda tidak dapat memanggil perintah Cypress biasa di dalam fungsi tersebut seperti Cypress.env(“apiHost”) atau cy.getCookie('auth_token') . Anda meneruskan hal-hal seperti string token auth atau host API backend ke objek argumen fungsi plugin Anda selain hal-hal yang diperlukan untuk badan permintaan jika perlu berbicara dengan API backend Anda.

Mengejek permintaan jaringan dengan cy.server() dan cy.route()

Untuk pengujian Cypress yang memerlukan data yang sulit untuk direproduksi (seperti variasi status UI penting pada halaman atau menangani panggilan API yang lebih lambat), satu fitur Cypress yang perlu dipertimbangkan adalah mematikan permintaan jaringan. Ini bekerja dengan baik dengan permintaan berbasis XmlHttpRequest (XHR) jika Anda menggunakan vanilla XMLHttpRequest, perpustakaan axios, atau jQuery AJAX. Anda kemudian akan menggunakan cy.server() dan cy.route() untuk mendengarkan rute untuk mengejek tanggapan untuk keadaan apa pun yang Anda inginkan. Berikut ini contohnya:

Kasus penggunaan lainnya adalah menggunakan cy.server() , cy.route() , dan cy.wait() bersama-sama untuk mendengarkan dan menunggu permintaan jaringan selesai sebelum melakukan langkah selanjutnya. Biasanya, setelah memuat halaman atau melakukan semacam tindakan pada halaman, isyarat visual intuitif akan memberi sinyal bahwa ada sesuatu yang selesai atau siap untuk kita tegaskan dan tindak lanjuti. Untuk kasus di mana Anda tidak memiliki isyarat yang terlihat, Anda dapat secara eksplisit menunggu panggilan API selesai seperti ini.

Salah satu masalah besar adalah jika Anda menggunakan ambil untuk permintaan jaringan, Anda tidak akan dapat mengejek permintaan jaringan atau menunggunya selesai dengan cara yang sama. Anda memerlukan solusi untuk mengganti window.fetch normal dengan polyfill XHR dan melakukan beberapa langkah penyiapan dan pembersihan sebelum pengujian Anda berjalan seperti yang dicatat dalam masalah ini . Ada juga properti experimentalFetchPolyfill pada Cypress 4.9.0 yang mungkin cocok untuk Anda, tetapi secara keseluruhan, kami masih mencari metode yang lebih baik untuk menangani pemutusan jaringan di seluruh pengambilan dan penggunaan XHR dalam aplikasi kami tanpa kerusakan. Pada Cypress 5.1.0, ada fungsi cy.route2() baru yang menjanjikan (lihat dokumen Cypress ) untuk penghentian jaringan eksperimental dari permintaan XHR dan pengambilan, jadi kami berencana untuk meningkatkan versi Cypress kami dan bereksperimen dengannya untuk melihat apakah itu memecahkan masalah kita.

Perintah khusus

Mirip dengan library seperti WebdriverIO, Anda dapat membuat perintah kustom global yang dapat digunakan kembali dan dirantai di seluruh file spesifikasi Anda, seperti perintah kustom untuk menangani login melalui API sebelum kasus pengujian Anda berjalan. Setelah Anda mengembangkannya dalam file seperti support/commands.ts , Anda dapat mengakses fungsi seperti cy.customCommand() atau cy.login() . Menulis perintah khusus untuk masuk terlihat seperti ini.

Tentang objek halaman

Objek halaman adalah pembungkus di sekitar pemilih dan berfungsi untuk membantu Anda berinteraksi dengan halaman. Anda tidak perlu membuat objek halaman untuk menulis pengujian, tetapi sebaiknya pertimbangkan cara untuk merangkum perubahan pada UI. Anda ingin membuat hidup Anda lebih mudah dalam hal mengelompokkan berbagai hal untuk menghindari pembaruan pemilih dan interaksi di banyak file daripada di satu tempat.

Anda dapat menentukan kelas "Halaman" dasar dengan fungsionalitas umum seperti open() untuk kelas halaman yang diwarisi untuk dibagikan dan diperluas. Kelas halaman turunan menentukan fungsi pengambilnya sendiri untuk pemilih dan fungsi pembantu lainnya saat menggunakan kembali fungsionalitas kelas dasar melalui panggilan seperti super.open() seperti yang ditunjukkan di sini.

Memilih untuk tidak menjalankan kode sisi klien dengan window.Cypress checks

Saat kami menguji alur dengan file unduhan otomatis seperti CSV, unduhan sering kali merusak pengujian Cypress kami dengan membekukan uji coba. Sebagai kompromi, kami terutama ingin menguji apakah pengguna dapat mencapai status sukses yang tepat untuk mengunduh dan tidak benar-benar mengunduh file dalam pengujian kami dengan menambahkan pemeriksaan window.Cypress .

Selama pengujian Cypress berjalan, akan ada properti window.Cypress yang ditambahkan ke browser. Dalam kode sisi klien Anda, Anda dapat memilih untuk memeriksa apakah tidak ada properti Cypress pada objek jendela, lalu lakukan pengunduhan seperti biasa. Tapi, jika sedang dijalankan dalam tes Cypress, jangan benar-benar mengunduh file tersebut. Kami juga memanfaatkan pemeriksaan properti window.Cypress untuk eksperimen A/B kami yang berjalan di aplikasi web kami. Kami tidak ingin menambahkan lebih banyak ketidakstabilan dan perilaku non-deterministik dari eksperimen A/B yang berpotensi menunjukkan pengalaman berbeda kepada pengguna pengujian kami, jadi pertama-tama kami memeriksa properti tersebut tidak ada sebelum menjalankan logika eksperimen seperti yang disorot di bawah ini.

Berurusan dengan iframe

Berurusan dengan iframe bisa jadi sulit dengan Cypress karena tidak ada dukungan iframe bawaan. Ada [masalah]( https://github.com/cypress-io/cypress/issues/136 ) yang sedang berjalan yang diisi dengan solusi untuk menangani iframe tunggal dan iframe bersarang, yang mungkin atau mungkin tidak berfungsi tergantung pada versi Cypress Anda saat ini atau iframe yang ingin Anda gunakan untuk berinteraksi. Untuk kasus penggunaan kami, kami membutuhkan cara untuk menangani iframe penagihan Zuora di lingkungan staging kami untuk memverifikasi alur peningkatan API Email dan API Kampanye Pemasaran. Pengujian kami melibatkan pengisian sampel informasi penagihan sebelum menyelesaikan peningkatan ke penawaran baru di aplikasi kami.

Kami membuat perintah khusus cy.iframe(iframeSelector) untuk merangkum berurusan dengan iframe. Melewati pemilih ke iframe kemudian akan memeriksa isi tubuh iframe hingga tidak lagi kosong dan kemudian mengembalikan kembali isi tubuh untuk dirantai dengan lebih banyak perintah Cypress seperti yang ditunjukkan di bawah ini:

Saat bekerja dengan TypeScript, Anda dapat mengetikkan perintah khusus iframe Anda seperti ini di file index.d.ts Anda:

Untuk menyelesaikan bagian penagihan dari pengujian kami, kami menggunakan perintah khusus iframe untuk mendapatkan konten isi iframe Zuora dan kemudian memilih elemen di dalam iframe dan mengubah nilainya secara langsung. Kami sebelumnya memiliki masalah dengan menggunakan cy.find(...).type(...) dan alternatif lain tidak bekerja, tapi untungnya kami menemukan solusi dengan mengubah nilai input dan memilih langsung dengan perintah panggilan yaitu cy.get(selector).invoke('val', 'some value') . Anda juga memerlukan ”chromeWebSecurity”: false di file konfigurasi cypress.json agar Anda dapat melewati kesalahan lintas asal. Cuplikan contoh penggunaannya dengan pemilih pengisi disediakan di bawah ini:

Standarisasi di seluruh lingkungan pengujian

Setelah menulis pengujian dengan Cypress menggunakan pernyataan, fungsi, dan pendekatan paling umum yang disoroti sebelumnya, kami dapat menjalankan pengujian dan membuatnya lulus pada satu lingkungan. Ini adalah langkah pertama yang bagus, tetapi kami memiliki banyak lingkungan untuk menerapkan kode baru dan untuk menguji perubahan kami. Setiap lingkungan memiliki kumpulan database, server, dan pengguna sendiri, tetapi pengujian Cypress kami harus ditulis hanya sekali untuk bekerja dengan langkah-langkah umum yang sama.

Untuk menjalankan pengujian Cypress terhadap beberapa lingkungan pengujian seperti dev, pengujian, dan staging sebelum akhirnya menerapkan perubahan ke produksi, kita perlu memanfaatkan kemampuan Cypress untuk menambahkan variabel lingkungan dan mengubah nilai konfigurasi untuk mendukung kasus penggunaan tersebut.

Untuk menjalankan pengujian Anda terhadap berbagai lingkungan frontend :

Anda perlu mengubah nilai "baseUrl" yang diakses melalui Cypress.config(“baseUrl”) agar sesuai dengan URL tersebut seperti https://staging.app.com atau https://testing.app.com . Ini mengubah URL dasar untuk semua panggilan cy.visit(...) Anda untuk menambahkan jalurnya. Ada beberapa cara untuk mengatur ini seperti pengaturan CYPRESS_BASE_URL=<frontend_url> sebelum menjalankan perintah atau pengaturan Cypress --config baseUrl=<frontend_url> .

Untuk menjalankan pengujian Anda terhadap lingkungan backend yang berbeda :

Anda perlu mengetahui nama host API seperti https://staging.api.com atau https://testing.api.com untuk mengatur variabel lingkungan seperti “apiHost” dan diakses melalui panggilan seperti Cypress.env(“apiHost”) . Ini akan digunakan untuk cy.request(...) Anda untuk membuat permintaan HTTP ke jalur tertentu seperti "<apiHost>/some/endpoint" atau diteruskan ke panggilan fungsi cy.task(...) Anda sebagai argumen lain properti untuk mengetahui backend mana yang harus dipukul. Panggilan yang diautentikasi ini juga perlu mengetahui token autentikasi yang kemungkinan besar Anda simpan di localStorage atau cookie melalui cy.getCookie(“auth_token”) . Pastikan token autentikasi ini pada akhirnya diteruskan sebagai bagian dari header "Otorisasi" atau melalui beberapa cara lain sebagai bagian dari permintaan Anda. Ada banyak cara untuk menyetel variabel lingkungan ini seperti langsung di file cypress.json atau di opsi baris perintah --env di mana Anda dapat merujuknya di dokumentasi Cypress .

Untuk mendekati masuk ke pengguna yang berbeda atau menggunakan metadata yang bervariasi:

Sekarang setelah Anda mengetahui cara menangani banyak URL frontend dan host API backend, bagaimana Anda menangani masuk ke pengguna yang berbeda? Bagaimana Anda menggunakan metadata yang bervariasi berdasarkan lingkungan, seperti hal-hal yang terkait dengan domain, kunci API, dan sumber daya lain yang cenderung unik di seluruh lingkungan pengujian?

Mari kita mulai dengan membuat variabel lingkungan lain yang disebut "testEnv" dengan kemungkinan nilai "pengujian" dan "pementasan" sehingga Anda dapat menggunakan ini sebagai cara untuk memberi tahu pengguna dan metadata lingkungan mana yang akan diterapkan dalam pengujian. Menggunakan variabel lingkungan "testEnv", Anda dapat mendekati ini dalam beberapa cara.

Anda dapat membuat file "staging.json" terpisah, "testing.json", dan file JSON lingkungan lainnya di bawah folder fixtures dan mengimpornya untuk Anda gunakan berdasarkan nilai "testEnv" seperti cy.fixture(`${testEnv}.json`).then(...) . Namun, Anda tidak dapat mengetik file JSON dengan baik dan ada lebih banyak ruang untuk kesalahan dalam sintaks dan dalam menulis semua properti yang diperlukan per pengujian. File JSON juga lebih jauh dari kode pengujian, jadi Anda harus mengelola setidaknya dua file saat mengedit pengujian. Masalah pemeliharaan serupa akan terjadi jika semua data uji lingkungan ditetapkan dalam variabel lingkungan langsung di cypress.json Anda dan akan ada terlalu banyak untuk dikelola di sejumlah besar pengujian.

Opsi alternatif adalah membuat objek perlengkapan pengujian dalam file spesifikasi dengan properti berdasarkan pengujian atau staging untuk memuat pengguna dan metadata pengujian tersebut untuk lingkungan tertentu. Karena ini adalah objek, Anda juga dapat menentukan tipe TypeScript generik yang lebih baik di sekitar objek perlengkapan uji untuk semua file spesifikasi Anda untuk digunakan kembali dan untuk menentukan tipe metadata. Anda akan memanggil Cypress.env(“testEnv”) untuk melihat lingkungan pengujian mana yang Anda jalankan dan menggunakan nilai itu untuk mengekstrak perlengkapan uji lingkungan yang sesuai dari objek perlengkapan uji keseluruhan dan menggunakan nilai-nilai itu dalam pengujian Anda. Gagasan umum objek perlengkapan uji dirangkum dalam cuplikan kode di bawahnya.

Menerapkan nilai konfigurasi Cypress "baseUrl", variabel lingkungan backend "apiHost", dan variabel lingkungan "testEnv" bersama-sama memungkinkan kita untuk memiliki pengujian Cypress yang bekerja terhadap beberapa lingkungan tanpa menambahkan beberapa kondisi atau aliran logika terpisah seperti yang ditunjukkan di bawah ini.

Mari kita mundur selangkah untuk melihat bagaimana Anda bahkan dapat membuat perintah Cypress Anda sendiri untuk dijalankan melalui npm. Konsep serupa dapat diterapkan pada benang, Makefile, dan skrip lain yang mungkin Anda gunakan untuk aplikasi Anda. Anda mungkin ingin menentukan variasi perintah "buka" dan "jalankan" untuk menyelaraskan dengan Cypress "buka" GUI dan "jalankan" dalam mode tanpa kepala terhadap berbagai lingkungan frontend dan backend di package.json Anda. Anda juga dapat mengatur beberapa file JSON untuk setiap konfigurasi lingkungan, tetapi untuk kesederhanaan, Anda akan melihat perintah dengan opsi dan nilai sebaris.

Anda akan melihat dalam skrip package.json bahwa frontend "baseUrl" Anda berkisar dari "http://localhost:9001" ketika Anda memulai aplikasi Anda secara lokal ke URL aplikasi yang digunakan seperti " https://staging.app. com ”. Anda dapat mengatur variabel backend "apiHost" dan "testEnv" untuk membantu membuat permintaan ke titik akhir backend dan memuat objek perlengkapan pengujian tertentu. Anda juga dapat membuat perintah "cicd" khusus ketika Anda perlu menjalankan pengujian dalam wadah Docker dengan kunci perekaman.

Beberapa takeaways

Ketika datang untuk memilih elemen, berinteraksi dengan elemen, dan menegaskan tentang elemen pada halaman, Anda bisa mendapatkan cukup jauh dengan menulis banyak tes Cypress dengan daftar kecil perintah Cypress seperti cy.get() , cy.contains() , .click() , .type() , .should('be.visible') .

Ada juga cara untuk membuat permintaan HTTP ke API backend menggunakan cy.request() , menjalankan kode arbitrer di server Node dengan cy.task() , dan mematikan permintaan jaringan menggunakan cy.server() dan cy.route() . Anda bahkan dapat membuat perintah khusus Anda sendiri seperti cy.login() untuk membantu Anda masuk ke pengguna melalui API. Semua hal ini membantu mengatur ulang pengguna ke titik awal yang tepat sebelum pengujian dijalankan. Bungkus pemilih dan fungsi ini sekaligus dalam sebuah file dan Anda telah membuat objek halaman yang dapat digunakan kembali untuk digunakan dalam spesifikasi Anda.

Untuk membantu Anda menulis pengujian yang lulus di lebih dari satu lingkungan, manfaatkan variabel lingkungan dan objek yang menyimpan metadata khusus lingkungan.

Ini akan membantu Anda menjalankan kumpulan pengguna yang berbeda dengan sumber daya data terpisah dalam spesifikasi Cypress Anda. Pisahkan perintah Cypress npm seperti npm run cypress:open:staging di package.json Anda akan memuat nilai variabel lingkungan yang tepat dan menjalankan tes untuk lingkungan yang Anda pilih untuk dijalankan.

Ini merangkum ikhtisar seribu kaki kami tentang menulis tes Cypress. Kami harap ini memberi Anda contoh dan pola praktis untuk diterapkan dan ditingkatkan dalam tes Cypress Anda sendiri.

Tertarik untuk mempelajari lebih lanjut tentang tes Cypress? Lihat sumber daya berikut:

• Apa yang Harus Dipertimbangkan Saat Menulis Tes E2E
• TypeScript Semua Hal dalam Tes Cypress Anda
• Berurusan Dengan Arus Email dalam Tes Cypress
• Ide untuk Mengonfigurasi, Mengatur, dan Mengonsolidasikan Tes Cypress Anda
• Mengintegrasikan Pengujian Cypress Dengan Docker, Buildkite, dan CICD