Mari Selami Cypress Untuk Pengujian End-to-End

Artikel ini disponsori oleh teman-teman terkasih kami di LambdaTest yang membuat pengalaman pengujian lintas-browser lebih lancar bagi banyak orang di seluruh dunia. Terima kasih!

Pengembangan perangkat lunak tanpa pengujian otomatis sulit dibayangkan saat ini. Variasi yang baik dari prosedur pengujian yang berbeda akan memastikan tingkat kualitas yang tinggi. Sebagai dasar untuk pengujian, kita dapat menggunakan sejumlah pengujian unit. Di atas itu, di tengah piramida, bisa dikatakan, adalah tes integrasi. Pengujian ujung ke ujung berada di bagian paling atas, mencakup kasus penggunaan yang paling kritis. Jenis pengujian ketiga inilah yang akan menjadi fokus artikel ini.

Namun, pengujian ujung ke ujung memang memiliki beberapa jebakan yang perlu dikhawatirkan:

• Pengujian end-to-end lambat dan, dengan demikian, menimbulkan rintangan yang signifikan dalam setiap strategi continuous integration dan continuous deployment (CI/CD). Tidak hanya itu, tetapi bayangkan menyelesaikan tugas, fitur, atau implementasi lainnya — menunggu pengujian dijalankan dapat menguras kesabaran semua orang.
• Pengujian end-to-end seperti itu sulit untuk dipertahankan, rawan kesalahan, dan mahal dalam segala hal karena upaya debugging. Berbagai faktor dapat menyebabkan hal ini. Tes Anda harus terasa seperti asisten, tidak pernah menjadi penghalang.
• Mimpi buruk terbesar bagi pengembang adalah tes yang tidak stabil, yang merupakan tes yang dijalankan dengan cara yang sama tetapi menghasilkan hasil yang berbeda. Ini seperti "Heisenbug", yang hanya terjadi jika Anda tidak mengukur aplikasi yang sedang diuji — yaitu, jika Anda tidak melihatnya.

Tapi jangan khawatir: Anda tidak harus menyerah pada perangkap ini. Mari kita lihat bagaimana mencegah banyak dari mereka . Namun, saya tidak akan hanya menjanjikan bulan dan tidak memberikan. Dalam panduan ini, kita akan menulis beberapa pengujian bersama, yang telah saya publikasikan untuk Anda di repositori GitHub. Dengan cara ini, saya berharap dapat menunjukkan kepada Anda bahwa pengujian akhir dapat menyenangkan! Mari kita mulai.

Apa itu Tes End-to-End?

Ketika berbicara tentang pengujian ujung ke ujung (atau E2E), saya suka menyebutnya sebagai "berbasis alur kerja". Frasa tersebut merangkum pengujian ujung-ke-ujung dengan baik: Ini mensimulasikan alur kerja pengguna yang sebenarnya dan harus mencakup sebanyak mungkin area fungsional dan bagian dari tumpukan teknologi yang digunakan dalam aplikasi. Pada akhirnya, komputer berpura-pura menjadi pelanggan dan mencoba berperilaku seperti pengguna sebenarnya. Pengujian ini paling baik untuk menerapkan tekanan konstan ke seluruh sistem aplikasi Anda dan, dengan demikian, merupakan ukuran yang bagus untuk memastikan kualitas saat seluruh tumpukan aplikasi ada.

Mari kita ingat kembali apa yang ingin kita capai dengan semua ini. Kita tahu bahwa pengujian front-end adalah serangkaian praktik untuk menguji UI aplikasi web, termasuk fungsinya. Masuk akal — dengan langkah-langkah ini, kami dapat memastikan bahwa aplikasi kami berfungsi dengan benar dan tidak ada perubahan di masa mendatang yang akan merusak kode kami. Untuk mencapai ini secara efisien, Anda mungkin bertanya-tanya apa dan berapa banyak yang perlu Anda uji.

Ini adalah pertanyaan yang valid. Anda mungkin menemukan satu jawaban yang mungkin dalam metafora: Piramida otomatisasi pengujian, yang pertama kali diperkenalkan oleh Mike Cohn dan selanjutnya ditentukan oleh Martin Fowler, menunjukkan cara membuat pengujian menjadi efisien . Kami menemukan pengujian unit yang cepat dan murah di tingkat piramida terendah, dan pengujian UI yang memakan waktu dan mahal (pengujian ujung ke ujung) di bagian atas.

Menjelaskan ini dan kelebihan dan kekurangannya akan cukup untuk artikelnya sendiri. Saya ingin fokus pada satu level. Pengujian end-to-end khususnya dapat membawa peningkatan kualitas yang signifikan jika diprioritaskan secara efisien. Dengan demikian, kami dapat terus-menerus membuat sistem kami tertekan dan memastikan bahwa fungsi utama aplikasi kami bekerja dengan benar.

Perjalanan Saya Ke Cypress

Ketika saya mulai belajar cara menulis tes ujung ke ujung, saya menggunakan Mink, perpustakaan PHP, di atas Behat, kerangka kerja pengembangan berbasis perilaku (BDD) berorientasi skenario. Saya mulai menggunakan Selenium, dengan segala kelebihan dan kekurangannya. Karena tim saya sudah mulai sering bekerja dengan Vue.js, kami mengubah kerangka kerja pengujian berbasis JavaScript untuk memastikan integrasi dan kompatibilitas yang sempurna. Pilihan kami saat itu adalah Nightwatch.js, jadi saya membangun rangkaian pengujian baru kami dari awal.

Selama ini, kami sering menemukan masalah kompatibilitas . Anda bisa menyebutnya neraka ketergantungan — belum lagi semua keterbatasan yang kami lihat dengan Selenium dan kemudian dengan WebDriver.

• Di tim kami, kami tidak dapat menemukan versi Chrome dari CI kami. Jadi, jika pembaruan untuk Chrome dirilis, Nightwatch.js tidak cukup cepat untuk kompatibel, menyebabkan banyak kegagalan dalam jalur pengujian kami.
• Jumlah penyebab uji coba yang tidak stabil mulai meningkat, karena kemungkinan menunggu Nightwatch.js tidak sesuai dengan produk kami secara optimal.

Jadi, kami mulai mempertimbangkan untuk membangun rangkaian pengujian kami yang baru. Setelah mengunjungi unconference, saya menemukan Cypress.

Cypress adalah kerangka kerja pengujian lengkap yang tidak menggunakan Selenium atau WebDriver. Alat ini menggunakan Node.js untuk memulai browser di bawah kontrol khusus. Pengujian dalam kerangka kerja ini dijalankan di tingkat browser, bukan hanya kendali jarak jauh. Itu menawarkan beberapa keuntungan.

Singkatnya, berikut adalah alasan mengapa saya memilih kerangka kerja ini:

• Kemampuan debugging yang sangat baik
  Test runner Cypress dapat melompat kembali ke status aplikasi apa pun melalui snapshot. Jadi, kita bisa langsung melihat kesalahan dan semua langkah sebelumnya. Selain itu, ada akses penuh ke alat pengembang Chrome (DevTools), dan klik direkam sepenuhnya.
• Cara yang lebih baik untuk menunggu tindakan dalam pengujian atau UI atau dalam tanggapan dari API
  Cypress menghadirkan penantian implisit, jadi tidak perlu pemeriksaan yang sesuai. Anda juga dapat membuat pengujian menunggu animasi dan respons API.
• Tes ditulis dalam JavaScript
  Ini mengurangi kurva belajar untuk menulis tes. Test runner Cypress adalah open-source, sehingga cocok dengan strategi produk kami.

Namun, artikel ini adalah panduan, jadi mari kita hentikan informasi umum ini dan mulai.

Mulai

Instal Dan Mulai Cypress

Mari kita mulai dari awal. Dalam pembicaraan saya tentang Cypress, saya biasanya mulai dengan membuat direktori baru melalui mkdir , dan kemudian segera menginstal Cypress. Cara termudah untuk menginstal ditunjukkan pada gambar ini:

Sedikit petunjuk: Jika Anda tidak ingin menggunakan npm, Anda dapat menginstal Cypress melalui Benang:

 yarn add cypress --dev

Alternatifnya adalah unduhan langsung, menggunakan folder ZIP yang disediakan Cypress. Itu dia! Setelah instalasi selesai, Anda siap untuk memulai.

Ada dua cara untuk mulai menjalankan tes Cypress. Yang pertama adalah dengan memulai Cypress di konsol, dan menjalankan pengujian Anda tanpa kepala:

 ./node_modules/.bin/cypress run

Cara kedua adalah dengan menggunakan salah satu fitur rapi Cypress, yaitu test runner terintegrasinya. Test runner adalah UI untuk menjalankan tes. Untuk meluncurkannya, Anda dapat menggunakan perintah serupa:

 ./node_modules/.bin/cypress open

Perintah ini akan membuka test runner. Saat Anda membuka Cypress untuk pertama kalinya, Anda akan melihat antarmuka ini:

Cypress menyediakan beberapa tes sampel yang telah ditulis sebelumnya untuk menampilkan fitur-fiturnya dan memberi Anda beberapa titik awal — inilah alasan tes yang tersedia. Mari kita abaikan itu untuk saat ini, karena kita ingin segera menulis milik kita sendiri. Namun, harap ingat area "Tes Integrasi" ini, karena ini akan menjelaskan banyak keajaiban yang akan terjadi nanti.

Kesan Pertama Struktur Cypress

Sekarang saatnya untuk membuka proyek kami yang baru dibuat di lingkungan pengembangan terintegrasi (IDE) pilihan. Jika Anda menavigasi ke folder ini, Anda akan melihat struktur pengujian berikut:

 smashing-example └── cypress └── fixtures └── integration └── plugins └── support └── cypress.json

Mari kita bahas folder-folder ini:

• fixtures
  Di sinilah Anda akan menemukan data pengujian tetap, yang tidak ada hubungannya dengan entitas lain. Jadi, tidak ada ID yang disimpan di sini, yang dapat berubah sesuai dengan keadaan setempat.
• integration
  Anda akan menemukan tes yang sebenarnya di sini.
• plugins
  Di sini, Anda dapat memperluas Cypress, baik dengan plugin Cypress yang ada atau milik Anda sendiri.
• support
  Di sini, Anda dapat memperluas Cypress itu sendiri. Perintah dan pembantu Anda sendiri ada di sini.
• cypress.json
  Ubah konfigurasi di sini, termasuk untuk lingkungan.

Baiklah, saya pikir kita dapat menemukan jalan di sekitar Cypress sekarang, apakah test runner atau kode sumber. Tapi bagaimana kita memulai? Apa yang ingin kita uji?

Pilih Kasus Uji

Tes ujung ke ujung yang khas bisa menjadi rumit, terutama jika memiliki banyak langkah. Akan memakan banyak waktu untuk mengeksekusi secara manual. Karena kerumitan ini, pengujian E2E dapat menjadi tantangan untuk diotomatisasi dan berjalan lambat. Akibatnya, kita perlu hati-hati memutuskan kasus mana yang akan diotomatisasi.

Menurut pendapat saya, istilah "berbasis alur kerja" adalah kuncinya : Kami akan memilih kasus uji berdasarkan cerita pengguna pada umumnya. Namun, karena waktu berjalan, tidak disarankan untuk mencakup setiap alur kerja yang tersedia. Oleh karena itu, kami membutuhkan cara untuk memprioritaskan kasus uji kami.

Di tim saya, kami memiliki beberapa kriteria untuk proyek kami. Kasus uji harus:

• mencakup alur kerja fitur yang paling umum dan paling sering digunakan, seperti operasi CRUD (istilah "jalur bahagia" menjelaskan alur kerja ini dengan cukup baik);
• gunakan analisis risiko, yang mencakup alur kerja dengan tes E2E yang paling rentan (yaitu di mana kesalahan akan menyebabkan kerusakan paling besar);
• menghindari liputan duplikat;
• tidak harus digunakan jika tes unit lebih sesuai (gunakan tes E2E untuk menguji respons perangkat lunak Anda terhadap kesalahan, bukan kesalahan itu sendiri).

Hal terpenting kedua yang perlu diingat adalah hanya menguji alur kerja yang ingin Anda uji secara eksplisit. Semua langkah lain yang diperlukan agar pengujian Anda berhasil harus dilakukan dengan operasi API di luar pengujian, untuk menghindari pengujian. Dengan cara ini, Anda akan memastikan waktu pengujian minimal dan mendapatkan hasil yang jelas dari kasus pengujian Anda jika gagal. Pikirkan alur kerja ini seperti yang akan dilakukan pengguna akhir: Fokus pada penggunaan fitur daripada pada implementasi teknis .

Contoh:

Jika Anda ingin menguji proses checkout di toko online, jangan lakukan semua langkah lain, seperti membuat produk dan kategori, meskipun Anda akan membutuhkannya untuk memproses checkout. Gunakan, misalnya, API atau dump database untuk membuat hal-hal ini, dan konfigurasikan pengujian hanya untuk checkout.

Contoh: Menemukan Artikel Saya di Majalah Smashing

Saya ingin menulis tes untuk situs web ini, Majalah Smashing. Saya tidak bisa menjamin bahwa tes ini akan up to date selamanya, tapi mari kita berharap itu akan bertahan lama. Either way, Anda akan dapat menemukan contoh ini di repositori GitHub.

Membuat Tes Cypress Pertama Kami

Di folder integration , kita akan mulai dengan membuat file baru. Sebut saja find-author.spec.js . Akhiran .spec berarti "spesifikasi". Dalam hal pengujian, ini mengacu pada detail teknis dari fitur atau aplikasi tertentu yang harus dipenuhi oleh aplikasi Anda.

Untuk mengubah file JavaScript kosong ini menjadi rumah pengujian, kita akan mulai dengan memberikan rangkaian pengujian strukturnya. Kami akan menggunakan metode yang disebut describe . describe() , atau context() , digunakan untuk menampung dan mengatur pengujian. Dengan kata lain, metode ini berfungsi sebagai kerangka untuk pengujian kami. Dengan demikian, file pengujian kami akan terlihat seperti ini:

 // find-author.spec.js describe('Find authors at smashing', () => { //... });

Langkah selanjutnya adalah membuat tes yang sebenarnya. Kami akan menggunakan metode it . it() , atau specify() , digunakan untuk mewakili tes yang sebenarnya. Seperti yang Anda lihat, kami dapat menangkap beberapa tes dalam satu file, yang memungkinkan beberapa opsi penataan yang sangat baik.

 // find-author.spec.js describe('Find authors at smashing', () => { it('Find the author Ramona Schwering', () => { cy.log('This is our brand-new test'); }); });

Sedikit petunjuk : Jika Anda sudah familiar dengan Mocha, Anda mungkin telah memperhatikan beberapa kesamaan. Cypress dibangun di atas Mocha, jadi sintaksnya sama.

Baiklah, mari kita lanjutkan. Jika kami menjalankan pengujian kami di test runner Cypress, kami akan melihat bahwa Cypress akan membuka browser untuk menjalankan pengujian. Browser ini terlihat pada tangkapan layar di bawah ini:

Selamat! Kami telah menulis tes pertama kami! Tentu, itu tidak banyak membantu. Kita perlu melanjutkan. Mari kita isi ujian kita dengan kehidupan.

Isi Ujian dengan Kehidupan

Apa hal pertama yang harus dilakukan saat menguji situs web? Benar, kita perlu membuka situs web. Kita bisa melakukannya dengan menggunakan perintah Cypress. Apa perintahnya, Anda mungkin bertanya-tanya?

Bekerja Dengan Perintah

Ada dua jenis instruksi yang digunakan dalam tes E2E. Jenis instruksi pertama, perintah, mewakili langkah-langkah individu dalam tes. Dalam konteks Cypress, perintah adalah segala sesuatu yang dilakukan Cypress untuk berinteraksi dengan situs web Anda. Interaksi ini bisa berupa apa saja — klik, scroll ke bawah situs web, atau bahkan menemukan elemen. Akibatnya, perintah akan menjadi salah satu hal penting yang akan kita isi pengujian kita.

Jadi, perintah pertama kita adalah perintah untuk menavigasi ke situs web — smashingmagazine.com . Perintah ini disebut visit .

Menggunakannya, pengujian kami akan terlihat seperti ini:

 // find-author.spec.js describe('Find authors at smashing', () => { it('Find the author Ramona Schwering', () => { cy.visit('https://www.smashingmagazine.com/'); }); });

Ada satu perintah yang sering saya gunakan — dan Anda juga akan melakukannya. Ini disebut get :

 cy.get('selector');

Perintah ini mengembalikan elemen sesuai dengan pemilihnya — mirip dengan jQuery $(…) . Jadi, Anda akan menggunakan perintah ini untuk menemukan bagian-bagian untuk berinteraksi. Biasanya, Anda akan menggunakannya untuk memulai rantai perintah. Tapi tunggu — apa yang dimaksud dengan rantai perintah?

Seperti yang disebutkan di awal artikel ini, semua tes dan semua hal lain yang menyertainya ditulis dalam JavaScript. Anda dapat menempatkan perintah dalam tes (yaitu pernyataan) dalam sebuah rantai (dirantai, dengan kata lain). Ini berarti bahwa perintah dapat meneruskan subjek (atau mengembalikan nilai) dari perintah ke perintah berikut, seperti yang kita ketahui dari banyak kerangka pengujian.

Baiklah, kita akan memulai rangkaian perintah dengan perintah get . Untuk menemukan elemen dengan get , kita perlu menemukan pemilihnya terlebih dahulu. Menemukan pemilih unik sangat penting, karena Cypress akan mengembalikan semua elemen yang cocok; jadi, ingatlah ini dan hindari jika tidak disengaja.

Berinteraksi Dengan Elemen

Cypress sendiri memiliki fitur untuk membantu Anda menemukan pemilih elemen yang ingin Anda kerjakan. Fitur ini disebut Selector Playground, dan membantu Anda menemukan pemilih unik dari suatu komponen atau melihat semua elemen yang cocok untuk pemilih atau string teks. Jadi, fitur ini dapat banyak membantu Anda dalam tugas ini. Untuk mengaktifkannya, cukup klik ikon crosshair di header UI pengujian Anda, lalu arahkan kursor ke elemen yang diinginkan:

Seperti yang terlihat pada tangkapan layar di atas, tooltip akan menampilkan pemilih saat melayang atau di bilah kecil ini di bawah ikon crosshair, yang muncul saat elemen diklik. Di bilah ini, Anda juga dapat melihat berapa banyak elemen yang cocok dengan pemilih yang diberikan — memastikan keunikannya dalam kasus kami.

Terkadang, pemilih yang dibuat secara otomatis itu mungkin bukan yang ingin Anda gunakan (misalnya jika panjang atau sulit dibaca atau tidak memenuhi kriteria Anda yang lain). Pemilih yang dihasilkan di bawah ini sulit untuk dipahami dan terlalu panjang, menurut pendapat saya:

Dalam hal ini, saya akan kembali ke DevTools browser untuk menemukan pemilih unik saya. Anda mungkin akrab dengan alat-alat ini; dalam kasus saya, saya sering memilih Chrome untuk tujuan ini. Namun, browser lain yang didukung mungkin menyediakan fitur serupa. Prosesnya terasa mirip dengan Selector Playground, kecuali bahwa kami menggunakan fitur DevTools di tab "Element".

Untuk memastikan bahwa pemilih itu unik, saya sarankan untuk mencarinya di tampilan kode DevTools Anda. Jika Anda hanya menemukan satu hasil, Anda dapat yakin bahwa itu unik.

Tahukah Anda bahwa ada banyak jenis pemilih yang berbeda ? Bergantung pada varietasnya, tes dapat terlihat dan bahkan berperilaku sangat berbeda. Beberapa varietas lebih cocok untuk pengujian ujung ke ujung daripada yang lain. Jika Anda ingin mengetahui pemilih mana yang digunakan untuk menjaga agar pengujian Anda tetap stabil dan bersih, saya dapat mengarahkan Anda ke salah satu artikel saya yang membahas masalah ini. Pengembang Cypress sendiri memberikan beberapa panduan tentang topik ini dalam praktik terbaik mereka.

Pengujian Kami Sebagai Urutan Perintah

Oke, kembali ke pengujian kita. Di dalamnya, kami ingin menampilkan alur kerja kami:

“Saya, sebagai pengguna, akan mencari artikel penulis dan menavigasi ke situs web penulis melalui area referensi di salah satu artikel mereka.”

Kami akan mereproduksi langkah-langkah yang akan dilakukan pengguna dengan menggunakan perintah. Saya akan menempelkan di bawah tes yang sudah selesai dengan komentar, yang akan menjelaskan langkah-langkahnya:

 // find-author.spec.js it('Find the author Ramona Schwering', () => { // Open the website cy.visit('https://www.smashingmagazine.com'); // Enter author's name in search field cy.get('#js-search-input').type('Ramona Schwering'); // Navigate to author's article cy.get('h2 > a').first().click(); // Open the author's page cy.get('.author-post__author-title').click(); });

Contoh ini berkaitan dengan alur kerja yang ingin kita uji. Cypress akan menjalankan tes ini. Jadi, apakah sudah waktunya untuk mengatakan "Selamat"? Apakah kita akhirnya selesai menulis tes pertama kita?

Nah, silakan lihat lebih dekat . Cypress akan menjalankannya, tetapi hanya akan melakukan apa yang diperintahkan oleh tes, yaitu apa pun yang Anda tulis. Jika Anda menjalankannya di runner pengujian, Anda dapat melihat apakah itu telah lulus — tetapi tidak jika Anda menjalankannya tanpa kepala. Dengan pengujian ini, kami hanya mengetahui apakah Cypress dapat menjalankan perintah kami dengan sukses — bukan apakah kami berakhir di situs web penulis. Jadi, kita perlu mengajarkan tes kita untuk menentukan itu.

Bekerja dengan Asersi

Jenis pernyataan kedua menangani deskripsi status UI yang diinginkan — yaitu, apakah sesuatu harus ada, terlihat, atau tidak lagi terlihat. Pernyataan di Cypress didasarkan pada pernyataan Chai dan Sinon-Chai, yang terlihat dalam sintaks.

Ingatlah bahwa kita ingin memeriksa apakah kita berada di halaman profil penulis — milik saya dalam contoh ini. Jadi, kita perlu menambahkan pernyataan untuk itu:

 // find-author.spec.js it('Find the author Ramona Schwering', () => { // Open the website cy.visit('https://www.smashingmagazine.com'); // Enter author's name in search field cy.get('#js-search-input').type('Ramona Schwering'); // Navigate to author's article cy.get('h2 > a').first().click(); // Open the author's page cy.get('.author-post__author-title').click(); // Check if we're on the author's site cy.contains('.author__title', 'Ramona Schwering').should('be.visible'); });

Baiklah, sekarang kami telah menulis tes yang memiliki nilai. Jadi, ya, selamat menulis tes pertama Anda ... meskipun itu belum sempurna.

Mari Jadikan Tes Kita Cantik

Bahkan jika kami telah berhasil menulis tes bermakna pertama dan mempelajari konsep inti dalam prosesnya, saya belum akan menggabungkan yang ini jika diusulkan dalam permintaan tarik. Beberapa hal yang tersisa untuk dilakukan untuk membuatnya bersinar.

Tidak usah buru-buru

Cypress memiliki opsi coba ulang bawaan di hampir setiap perintah, jadi Anda tidak perlu menunggu untuk melihat apakah, misalnya, suatu elemen sudah ada. Namun, ini hanya melihat apakah ada elemen di DOM, tidak lebih dari itu. Cypress tidak dapat memprediksi semua yang dilakukan aplikasi Anda, jadi mungkin ada beberapa kelemahan jika Anda hanya mengandalkan ini.

Apa yang akan dilakukan pengguna jika mereka ingin melihat situs web yang masih memuat? Mereka kemungkinan besar akan menunggu sampai beberapa bagian dari situs web menjadi terlihat (dengan demikian, dimuat) dan kemudian akan berinteraksi dengan mereka. Dalam pengujian kami, kami ingin meniru dengan tepat bahwa: Kami ingin menunggu perubahan di UI sebelum mulai berinteraksi . Dalam kebanyakan kasus, kami akan membatasi perilaku ini pada elemen yang kami butuhkan, sehingga menggunakan pernyataan pada elemen tersebut.

Seperti yang Anda lihat, kami harus membuat pengujian kami menunggu beberapa kali. Namun, menunggu terlalu banyak juga tidak baik. Sebagai aturan praktis, saya sarankan menggunakan pernyataan untuk memeriksa apakah elemen yang akan diinteraksikan telah dimuat sepenuhnya, sebagai langkah pertama untuk menentukan apakah situs web yang sedang diuji telah dimuat.

Mari kita lihat bagian dari pengujian kami sebagai contoh. Saya menambahkan satu pernyataan untuk memastikan halaman kami telah terisi penuh :

 // find-author-assertions.spec.js // Open website cy.visit('https://www.smashingmagazine.com'); // Ensure site is fully loaded cy.get('.headline-content').should('be.visible'); // Enter author's name in the search field cy.get('#js-search-input').type('Ramona Schwering');

Terus tambahkan pernyataan sedemikian rupa ke semua contoh di mana situs web kami akan memiliki waktu pemuatan atau beberapa elemen yang perlu dirender lagi. Untuk file pengujian lengkap, silakan lihat pengujian terkait di repositori GitHub.

Untuk menghindari jatuh ke dalam perangkap tes yang tidak stabil, saya ingin memberi Anda satu petunjuk terakhir: Jangan pernah menggunakan waktu tunggu yang tetap, seperti cy.wait(500) atau sejenisnya.

Tanggapan API Adalah Teman Anda

Ada satu kemungkinan menunggu yang rapi khususnya yang saya suka gunakan dalam pengujian saya. Di Cypress, dimungkinkan untuk bekerja dengan fitur jaringan — cara lain yang berguna untuk menunggu di aplikasi Anda adalah dengan menggunakan fitur ini untuk bekerja dengan permintaan jaringan . Dengan cara ini, Anda dapat membuat pengujian menunggu respons API yang berhasil.

Jika kita mengingat alur kerja kita sebagai contoh, satu langkah dapat memanfaatkan kemungkinan menunggu API. Aku sedang berpikir tentang pencarian. Kisah pengguna yang sesuai dapat berupa sebagai berikut:

“Saya, sebagai pengembang, ingin memastikan bahwa hasil pencarian kami telah dimuat sepenuhnya sehingga tidak ada artikel dari hasil lama yang akan menyesatkan pengujian kami.”

Mari kita terapkan itu pada pengujian kita. Pertama-tama, kita perlu menentukan rute yang ingin kita tunggu nanti. Kita dapat menggunakan perintah intercept untuk ini. Saya akan mencari permintaan, membawa data yang saya butuhkan — hasil pencarian dalam kasus ini.

Agar contoh ini tetap sederhana, saya akan menggunakan wildcard untuk URL. Setelah itu, saya akan menggunakan alias agar Cypress bisa bekerja dengan rute ini nanti.

 // find-author-hooks.spec.js // Set the route to work with it('Find the author Ramona Schwering', () => { // Route to wait for later cy.intercept({ url: '*/indexes/smashingmagazine/*', method: 'POST' }).as('search'); // With this alias Cypress will find the request again //...

Di Cypress, semua rute yang ditentukan ditampilkan di awal pengujian. Jadi, saya juga ingin meletakkan perintah intercept itu di awal pengujian saya.

Sekarang, kita dapat menggunakan alias rute ini dalam pernyataan. Cara paling ramping untuk melakukan ini adalah dengan perintah wait Cypress, langsung dengan alias yang disebutkan sebelumnya. Namun, menggunakan perintah ini saja akan menyebabkan menunggu respons terlepas dari hasilnya . Bahkan kode kesalahan seperti 400 atau 500 akan dihitung sebagai lulus, sedangkan aplikasi Anda kemungkinan besar akan rusak. Jadi saya sarankan menambahkan pernyataan lain seperti ini:

 // find-author-hooks.spec.js // Later: Assertion of the search request's status code cy.wait('@search') .its('response.statusCode').should('equal', 200);

Dengan cara ini, kita dapat menunggu data perangkat lunak, perubahan, dan sebagainya dengan presisi, tanpa membuang waktu atau mengalami masalah jika aplikasi sangat tertekan. Sekali lagi, Anda dapat menemukan file contoh lengkap di repositori GitHub saya.

Mengonfigurasi Cypress

Saya telah meninggalkan satu detail kecil. Jika Anda melihat lebih dekat pada contoh pengujian lengkap, itu sedikit berbeda dari yang kami gunakan di sini dalam panduan ini.

 // Cypress describe('Find author at smashing', () => { beforeEach(() => { // Open website cy.visit('https://www.smashingmagazine.com'); }); //...

Saya hanya menggunakan garis miring untuk membuka situs Smashing Magazine. Bagaimana cara kerjanya? Nah, menggunakan perintah ini seperti itu akan menavigasi ke baseUrl pengujian kami. baseUrl adalah nilai konfigurasi yang dapat digunakan sebagai awalan untuk URL perintah cy.visit() atau cy.request() . Di antara nilai lainnya, kita dapat mendefinisikan nilai ini di file cypress.json . Untuk pengujian kami, kami akan mengatur baseUrl seperti ini:

 // cypress.json { "baseUrl": "https://www.smashingmagazine.com" }

Sebutan Terhormat: Hooks

Ada satu topik tersisa yang ingin saya sebutkan, bahkan jika tes contoh kami tidak cocok untuk menggunakannya. Seperti biasa dalam kerangka pengujian lainnya, kita dapat menentukan apa yang terjadi sebelum dan sesudah pengujian melalui apa yang disebut lifecycle hooks . Lebih tepatnya, ini ada untuk mengeksekusi kode sebelum atau setelah satu atau semua tes:

 // Cypress describe('Hooks', function() { before(() => { // Runs once before all tests }); after(() => { // Runs once after all tests }); beforeEach(() => { // Runs before each test }); afterEach(() => { // Runs after each test }); });

Kami ingin mengisi file pengujian kami dengan lebih dari satu pengujian, jadi kami harus mencari langkah-langkah umum yang ingin kami jalankan sebelum atau sesudahnya. Baris pertama kami adalah contohnya, menjadi perintah visit . Dengan asumsi kita ingin membuka situs web ini sebelum masing-masing pengujian ini, hook beforeEach dalam contoh kita akan terlihat seperti ini:

 // Cypress describe('Find author at smashing', () => { beforeEach(() => { // Open website cy.visit('https://www.smashingmagazine.com'); }); //... 

Saya sering menggunakan ini dalam pekerjaan sehari-hari saya untuk memastikan, misalnya, bahwa aplikasi saya diatur ulang ke keadaan default sebelum test , sehingga mengisolasi tes dari tes lain. ( Jangan pernah mengandalkan pengujian sebelumnya! ) Jalankan pengujian Anda secara terpisah satu sama lain untuk mempertahankan kontrol atas status aplikasi.

Setiap pengujian harus dapat berjalan sendiri — terlepas dari pengujian lainnya. Ini penting untuk memastikan hasil tes yang valid . Untuk detail tentang ini, lihat bagian “Data yang Kami Bagikan” di salah satu artikel terbaru saya. Untuk saat ini, lihat contoh lengkap di GitHub jika Anda ingin melihat keseluruhan pengujian.

Kesimpulan

Menurut pendapat saya, pengujian end-to-end adalah komponen penting dari CI, menjaga kualitas aplikasi pada tingkat tinggi dan pada saat yang sama meringankan pekerjaan penguji. Cypress adalah alat pilihan saya untuk men-debug pengujian ujung ke ujung dengan cepat, stabil, dan efisien, dan untuk menjalankannya secara paralel dengan permintaan tarik apa pun sebagai bagian dari CI. Kurva pembelajarannya lembut jika Anda sudah terbiasa dengan JavaScript.

Saya harap saya dapat memandu Anda sedikit dan memberi Anda titik awal untuk menulis tes Cypress dan beberapa tip praktis untuk memulai. Tentu saja, semua contoh kode tersedia di repositori GitHub, jadi silakan lihat.

Tentu saja, ini hanya titik awal; ada lebih banyak hal untuk dipelajari dan didiskusikan mengenai tes Cypress — saya akan meninggalkan Anda dengan beberapa saran tentang apa yang harus dipelajari selanjutnya. Dengan mengingat hal ini, selamat menguji!

Sumber daya

• Contoh smash asli, Ramona Schwering
  Repositori GitHub untuk contoh dalam artikel ini.
• Dokumentasi Cypress
• "Resep", Cypress
  Pilihan contoh, resep, dan kursus.
• “Belajar Membuat Kode Dengan JavaScript: Cypress” (pelajaran), CodeLikeThis
• Praktik Terbaik dalam Menulis Tes End-to-End”, Dokumen Shopware