Apa yang Harus Dipertimbangkan Saat Menulis Tes E2E #frontend@twiliosendgrid

Di Twilio SendGrid, kami menulis pengujian end-to-end (E2E) menjelang akhir fitur baru atau siklus pengembangan halaman untuk memastikan semua bagian terhubung dan bekerja dengan baik antara frontend dan backend dari perspektif pengguna akhir.

Kami telah bereksperimen dengan berbagai kerangka kerja dan pustaka pengujian E2E seperti kerangka kerja Ruby Selenium kustom kami sendiri, WebdriverIO, dan terutama, Cypress selama lebih dari dua tahun seperti yang disorot di bagian satu dan bagian dua dari seri posting blog yang mendokumentasikan migrasi kami di semua solusi. Terlepas dari kerangka kerja atau pustaka yang kami gunakan, kami mendapati diri kami mengajukan pertanyaan yang sama tentang fitur apa yang dapat kami otomatisasi dan tulis untuk pengujian E2E. Setelah mengidentifikasi fitur mana yang dapat kami uji, kami juga menyadari bahwa kami menerapkan strategi umum yang sama berulang kali untuk menulis dan menyiapkan pengujian.

Posting blog ini tidak memerlukan pengetahuan sebelumnya tentang menulis tes E2E di perpustakaan atau kerangka kerja tertentu, tetapi ini membantu jika Anda pernah melihat aplikasi web dan bertanya-tanya tentang cara terbaik untuk mengotomatisasi hal-hal di browser untuk menguji halaman bekerja dengan benar. Kami bertujuan untuk memandu Anda melalui cara berpikir tentang tes E2E, sehingga Anda dapat menerapkan pertanyaan-pertanyaan ini dan strategi umum untuk menulis tes ke kerangka kerja apa pun yang Anda pilih.

Pertanyaan untuk ditanyakan apakah Anda dapat mengotomatiskan tes E2E

Saat menulis tes E2E, kita perlu memastikan aliran di halaman yang kita uji dalam aplikasi kita memenuhi kriteria tertentu. Mari kita telusuri beberapa pertanyaan tingkat tinggi yang kita ajukan pada diri sendiri untuk menentukan apakah tes E2E dapat diotomatisasi.

1. Apakah mungkin untuk mengatur ulang data pengguna kembali ke keadaan tertentu sebelum setiap pengujian melalui beberapa cara yang dapat diandalkan seperti API? Jika tidak ada cara untuk mereset pengguna secara andal kembali ke status yang Anda inginkan, itu tidak dapat diotomatisasi dan diharapkan berjalan sebagai bagian dari pengujian pemblokiran Anda sebelum penerapan. Ini juga merupakan antipattern dan biasanya non-deterministik untuk mengembalikan pengguna ke status tertentu melalui UI karena lambat dan mengotomatiskan langkah melalui UI sudah cukup tidak stabil. Lebih dapat diandalkan untuk membuat panggilan API untuk mengatur ulang status pengguna tanpa harus membuka halaman di browser. Alternatif lain, jika Anda memiliki layanan yang ada, adalah membuat pengguna baru sebelum setiap pengujian dengan data yang tepat. Selama kami mengatur ulang pengguna yang bertahan atau membuat pengguna sebelum setiap pengujian, kami kemudian dapat fokus pada bagian yang kami uji di halaman.

2. Apakah kami memiliki kendali atas fitur, API, atau sistem yang ingin kami uji? Jika itu adalah layanan pihak ketiga yang Anda andalkan untuk penagihan atau fitur lainnya, apakah ada cara untuk mengejeknya atau membuatnya bekerja secara deterministik dengan nilai tertentu? Anda ingin mendapatkan kontrol sebanyak mungkin atas pengujian untuk mengurangi kerapuhan. Anda dapat membuat pengguna pengujian khusus dengan sumber daya atau data yang terisolasi per pengujian yang dijalankan sehingga tidak dapat dipengaruhi oleh hal lain.

3. Apakah layanan atau fitur itu sendiri cukup konsisten untuk bekerja dalam batas waktu yang wajar? Seringkali Anda mungkin harus menerapkan polling atau menunggu data tertentu diproses dan membuatnya ke database (seperti pembaruan asinkron yang lebih lambat dan peristiwa email yang dipicu). Jika layanan tersebut sering terjadi dalam jangka waktu yang wajar dan andal, Anda dapat mengatur batas waktu polling yang tepat saat Anda menunggu elemen DOM tertentu muncul atau data diperbarui.

4. Bisakah kita memilih elemen yang kita perlukan untuk berinteraksi di halaman? Apakah Anda berurusan dengan iframe atau elemen yang dihasilkan yang tidak dapat Anda kendalikan dan tidak dapat ubah? Untuk berinteraksi dengan elemen pada halaman, Anda dapat menambahkan pemilih yang lebih spesifik seperti atribut `data-hook` atau `data-testid` daripada memilih id atau nama kelas. Id dan nama kelas lebih mudah berubah karena biasanya dikaitkan dengan gaya. Bayangkan mencoba memilih nama atau id kelas hash dari komponen gaya atau modul CSS sebaliknya. Untuk elemen yang dibuat pihak ketiga atau pustaka komponen sumber terbuka seperti react-select, Anda bisa membungkus elemen tersebut dengan elemen induk dengan atribut `data-hook` dan memilih turunan di bawahnya. Untuk menangani iframe, kami membuat perintah khusus untuk mengekstrak elemen DOM yang perlu kami tegaskan dan tindak lanjuti, yang akan kami berikan contoh nanti.

Ada lebih banyak pertimbangan untuk dipertimbangkan, tetapi semuanya bermuara pada satu pertanyaan: Bisakah kita mengulangi tes E2E ini secara konsisten dan tepat waktu dan mencapai hasil yang sama?

Strategi umum untuk menulis tes E2E

1. Cari tahu kasus uji bernilai tinggi yang dapat kita otomatisasi . Beberapa contoh termasuk pengujian jalur bahagia yang mencakup sebagian besar aliran fitur: melakukan operasi CRUD melalui UI untuk informasi profil pengguna, memfilter tabel untuk mencocokkan hasil yang diberikan beberapa data, membuat postingan, atau menyiapkan kunci API. Kasus tepi dan penanganan kesalahan lainnya, bagaimanapun, mungkin lebih baik untuk ditutup dengan tes unit dan integrasi. Jalankan melalui pertanyaan yang kami sebutkan di bagian sebelumnya untuk membantu mempersingkat daftar kasus uji Anda.

2. Pikirkan tentang cara mengulang pengujian ini dengan menyiapkan atau merobohkan API sebanyak mungkin. Untuk kasus pengujian yang bernilai tinggi dan dapat diotomatisasi, mulailah mencatat hal-hal mana yang harus Anda siapkan melalui API. Beberapa contoh adalah menyemai pengguna dengan data yang tepat jika pengguna tidak memiliki cukup data yang dapat difilter untuk pagination, jika data pengguna kedaluwarsa pada jendela bergulir 30 hari, atau jika kami mungkin perlu merobohkan beberapa data yang tersisa dari yang berhasil atau tidak lengkap tes sebelum tes saat ini dimulai lagi. Pengujian harus dapat berjalan dan mengatur dirinya sendiri dalam keadaan berulang yang sama terlepas dari bagaimana pengujian terakhir berhasil atau gagal.

Penting untuk dipikirkan: bagaimana saya bisa mengatur ulang data pengguna ini kembali ke titik awal sehingga saya hanya dapat menguji bagian dari fitur yang saya inginkan?

Misalnya, jika Anda ingin menguji kemampuan pengguna untuk menambahkan kiriman sehingga akhirnya muncul di daftar kiriman pengguna, kiriman tersebut harus dihapus terlebih dahulu.

3. Berjalan di posisi pelanggan Anda dan lacak langkah-langkah UI yang diperlukan untuk menyelesaikan alur fitur sepenuhnya. Catat langkah-langkah bagi pelanggan untuk menyelesaikan alur atau tindakan penuh. Lacak apa yang harus atau tidak boleh dilihat atau berinteraksi dengan pengguna setelah setiap langkah. Kami akan melakukan pemeriksaan kewarasan dan pernyataan di sepanjang jalan untuk memastikan pengguna menghadapi urutan peristiwa yang tepat untuk tindakan mereka. Kami kemudian akan menerjemahkan pemeriksaan kewarasan menjadi perintah dan pernyataan otomatis.

4. Pertahankan perubahan dan otomatisasi alur dengan menambahkan pemilih tertentu dan menerapkan objek halaman (atau jenis pembungkus lainnya). Tinjau langkah-langkah yang Anda tulis untuk mengetahui cara bermanuver dan menjalani alur fitur. Tambahkan pemilih yang lebih spesifik seperti atribut `data-hook` ke elemen yang berinteraksi dengan pengguna seperti tombol, modal, input, baris tabel, peringatan, dan kartu. Jika mau, Anda dapat membuat objek halaman, pembungkus, atau file pembantu dengan referensi ke elemen tersebut melalui pemilih yang Anda tambahkan. Anda kemudian dapat menerapkan fungsi yang dapat digunakan kembali untuk berinteraksi dengan elemen halaman yang dapat ditindaklanjuti.

5. Terjemahkan langkah-langkah pengguna yang Anda rekam ke dalam pengujian Cypress dengan bantuan yang Anda buat. Dalam pengujian, kami biasanya masuk ke pengguna melalui API dan mempertahankan cookie sesi sebelum setiap kasus pengujian berjalan agar tetap masuk. Kami kemudian menyiapkan atau menghancurkan data pengguna melalui API agar memiliki titik awal yang konsisten. Dengan semua yang ada, kami mengunjungi halaman yang akan kami uji langsung untuk fitur kami. Kami melanjutkan dengan menjalankan langkah-langkah untuk alur seperti membuat, memperbarui, atau menghapus alur, menegaskan apa yang harus terjadi atau terlihat di halaman di sepanjang jalan. Untuk mempercepat pengujian dan mengurangi kerapuhan, hindari mengatur ulang atau membangun status melalui UI dan melewati hal-hal seperti masuk melalui halaman masuk atau menghapus sesuatu melalui UI untuk fokus pada bagian yang ingin Anda uji. Pastikan untuk selalu melakukan bagian-bagian tersebut di hook `before` atau `beforeEach`. Jika tidak, jika Anda menggunakan hook `after` atau `afterEach`, pengujian mungkin gagal di antaranya, sehingga langkah pembersihan Anda tidak pernah dijalankan dan menyebabkan pengujian berikutnya gagal.

6. Palu dan hancurkan uji kerapuhan. Setelah menerapkan pengujian dan lulus beberapa kali secara lokal, Anda tergoda untuk menyiapkan permintaan tarik, menggabungkannya segera, dan menjalankan pengujian sesuai jadwal dengan rangkaian pengujian lainnya atau memicunya dalam langkah penerapan Anda. Sebelum Anda melakukannya:

1. 1. Pertama, coba tinggalkan pengguna di berbagai status dan lihat apakah pengujian Anda masih lulus untuk memastikan Anda memiliki langkah penyiapan yang tepat.
   2. Selanjutnya, selidiki menjalankan pengujian Anda secara paralel saat dipicu selama salah satu alur penerapan Anda. Ini memungkinkan Anda untuk melihat apakah sumber daya sedang diinjak oleh pengguna yang sama dan jika ada kondisi balapan yang terjadi.
   3. Kemudian, amati bagaimana pengujian Anda berjalan dalam mode tanpa kepala di wadah Docker untuk melihat apakah Anda mungkin perlu menaikkan batas waktu atau menyesuaikan pemilih apa pun.

Tujuannya adalah untuk melihat bagaimana pengujian Anda berperilaku di pengujian berulang dalam kondisi yang berbeda dan membuatnya sestabil dan sekonsisten mungkin sehingga kami menghabiskan lebih sedikit waktu untuk memperbaiki pengujian dan lebih fokus untuk menangkap bug yang sebenarnya di lingkungan kami.

Berikut adalah contoh tata letak boilerplate uji Cypress tempat kami membuat perintah dukungan global masuk yang disebut `cy.login(nama pengguna, kata sandi).` Kami menyetel cookie secara eksplisit dan menyimpannya sebelum setiap kasus uji sehingga kami dapat tetap masuk dan langsung masuk ke halaman yang kami uji. Kami juga melakukan beberapa pengaturan atau pembongkaran melalui API dan melewati halaman login setiap kali seperti yang ditunjukkan di bawah ini.

Mengakhiri pikiran

Selain membandingkan solusi E2E mana yang terbaik untuk digunakan, penting juga untuk mengadopsi pola pikir yang tepat untuk pengujian E2E. Sangat penting untuk terlebih dahulu mengajukan pertanyaan tentang apakah fitur yang ingin Anda uji sesuai dengan persyaratan untuk diotomatisasi. Seharusnya ada cara bagi Anda untuk menyetel ulang pengguna atau data kembali ke status tertentu dengan andal (seperti melalui API) sehingga Anda dapat fokus pada apa yang Anda coba validasi.

Jika tidak ada cara yang dapat diandalkan untuk menyetel ulang pengguna atau data Anda ke titik awal yang tepat, Anda harus melihat ke dalam membangun alat dan API untuk membuat pengguna dengan konfigurasi tertentu. Anda juga dapat mempertimbangkan untuk mengolok-olok hal-hal yang dapat Anda kendalikan untuk membuat pengujian sestabil dan sekonsisten mungkin. Jika tidak, Anda harus mempertimbangkan nilai dan pengorbanan dengan tim Anda. Apakah fitur ini yang harus Anda tinggalkan untuk pengujian unit atau pengujian regresi manual ketika perubahan kode baru didorong?

Untuk fitur-fitur yang dapat Anda otomatisasi dalam pengujian E2E, seringkali paling berharga untuk mencakup alur jalur bahagia utama pengguna Anda. Sekali lagi, buat hal-hal dapat diulang secara tepat waktu dan konsisten dan hilangkan kerapuhan saat Anda menulis tes E2E dengan kerangka kerja atau pustaka apa pun yang Anda inginkan.

Untuk informasi lebih lanjut tentang tes Cypress E2E khusus, lihat sumber daya berikut:

• 1.000 Kaki Ikhtisar Menulis Tes Cypress
• 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