Pada ujian frontend yang berkesan

Telah menemu duga agak lama. Apa yang menonjol dalam proses yang menyakitkan ini ialah temu bual itu akan ditakdirkan jika persoalan ujian dibangkitkan sama sekali. Ini kerana pengalaman saya terutamanya dalam pembangunan bahagian hadapan dan dua syarikat yang saya tinggali sangat lemah dalam ujian bahagian hadapan.

--- Skip kalau nak terus ke perbincangan ---

Kekurangan saya, dalam erti kata tertentu, adalah hasil sampingan budaya industri. Ujian frontend sentiasa menjadi satu perkara, tetapi sejak sedekad lalu struktur syarikat telah memisahkan kebimbangan ujian daripada proses pembangunan. Jadi kami mempunyai pasukan QA khusus yang akan menulis ujian E2E/automatik untuk kami pembangun. Jadi ujian tidak ada dalam huraian kerja. Juga kebenaran malang permulaan kecil ialah penghantaran sentiasa melebihi segala-galanya, jadi memandangkan ujian menghalang produktiviti, kami pembangun tidak menguji. Kami tidak mempunyai sebarang perpustakaan ujian (Jasmine/Mocha/PhantomJS...) dipasang dalam repo.

Saya mendapat pekerjaan kedua saya di sebuah syarikat yang jauh lebih besar (pasukan platform pengguna mempunyai 150 pembangun?). Walau bagaimanapun, tidak ada ujian yang terlalu penting. Setiap pasukan (pasukan dibahagikan mengikut ciri seperti daftar keluar, kesetiaan, pendaftaran...) sekali lagi mempunyai ahli QA yang berdedikasi yang akan menulis ujian E2E tersebut. Setelah budaya itu wujud dan QA dipotong daripada belanjawan, tiada siapa yang mengambilnya kerana tiada sesiapa yang boleh mempelajarinya. Saya cuba mengambil beberapa ujian E2E untuk pasukan kami, tetapi kod yang ditinggalkan tidak berfungsi dan penuh dengan pepijat yang jelas (banyak WTF). Digabungkan dengan tarikh akhir yang ketat LAGI, ujian ketinggalan. Satu-satunya masa orang bercakap tentang ujian adalah untuk fungsi utiliti dan cangkuk tindak balas tersuai.

--- perbincangan bermula ---

Oleh kerana dibelenggu oleh budaya tanpa ujian, saya perlu sekurang-kurangnya menghasilkan sesuatu yang boleh saya katakan semasa temu bual tentang ujian secara abstrak. Saya akan melangkaui omong kosong biasa yang tidak menguji gaya atau pelaksanaan apa yang tidak.

Jangan ragu untuk menambah perbincangan. Ini menjejaskan sekurang-kurangnya 300 rakan sekerja saya yang lalu!

1.) menguji keadaan global:
Dalam pengalaman saya, salah satu ciri yang paling menggerutu ialah jenis tingkah laku "jika ini berlaku, kami akan melakukan ini untuk anda secara automatik". Sebagai contoh, satu aplikasi yang saya ada ialah papan pemuka visualisasi graf yang boleh dikonfigurasikan secara meluas. Satu perubahan konfigurasi boleh menyebabkan konfigurasi lain turut berubah, bergantung pada data yang dikembalikan dan apa yang tidak. Beberapa kesan sampingan konfigurasi tidak lurus ke hadapan. Oleh itu, anda perlu menguji perubahan konfigurasi automatik dan sama ada keadaan itu berterusan/tidak berubah/konsisten di seluruh papan. Jadi, jika anda telah menguji tentang jenis tingkah laku ini, selaras dengan PM, pengurus, reka bentuk dan pasukan QA adalah sangat berharga.

2.) jangan luangkan banyak masa untuk menguji integriti input UI:
Saya melihat beberapa tutorial bercakap tentang input ujian, seperti apabila saya menaip "taylor swift" ke dalam bar carian dan tekan enter, maka fungsi carian kami akan mendapat taylor swift sebagai input.

Ini langsung tidak membantu. Jika pengikatan data anda rosak, sama ada ia akan menjadi sangat jelas bahawa anda sepatutnya menangkapnya sendiri semasa pembangunan atau ia tidak boleh diuji secara automatik kerana ada sesuatu yang menghalang kefungsian, seperti div yang tidak kelihatan di atas bar carian supaya pengguna tidak boleh menaip dalam carian.

jika anda dibayar melalui baris kod sekalipun, teruskan :)

3.) input ujian sebagai kesan sampingan input walaupun adalah wajar:
bertentangan dengan nombor 2, anda perlu menguji panggilan berfungsi yang sepenuhnya kesan sampingan kepada interaksi pengguna. Contohnya, apabila pengguna mengklik butang, permintaan harus dipanggil untuk mendaftarkan tindakan pengguna ini untuk analisis data. Kesan sampingan jenis ini yang berasingan sepenuhnya daripada fungsi teras ini, harus diuji secara automatik supaya kita tidak terperangkap oleh beberapa perubahan yang tidak disengajakan. Kesan sampingan bukan teras boleh menjadi penting kepada pasukan lain, saya pernah menyertai salah satu pasukan lain seperti itu :D

Jadi bagaimana anda mengarkitek keperluan ujian ini?
mari kita pecahkan seni bina bahagian hadapan: MVC (anda boleh mengatakan anda MVVM atau apa yang tidak, ia tidak begitu penting).

V - paparan (html/jsx): Ini bagus untuk ujian penyemak imbas E2E/tanpa kepala dan merupakan standard industri.

C - pengawal (logik perniagaan): luangkan sedikit masa untuk memastikan fungsinya betul. Sebagai contoh, jika anda mempunyai/abstrak kepada fungsi tulen, adakah proses input-output yang dijangkakan masih berjalan lancar? Agak standard industri, tetapi orang ramai biasanya tidak bersusah payah menjadikan fungsi stateful menjadi fungsi dan ujian tulen.

M - model (panggilan/nyatakan api): inilah yang paling saya mahu fokuskan. keadaan (bukan rendering) anda hendaklah global dan tunggal bagi setiap konsep. Bukan idea baru, kerana Redux pada dasarnya ia. Walau bagaimanapun, ia tidak semestinya Flux untuk tujuan ujian kami. Anda boleh mempunyai atom jotai tetapi anda boleh mengekodkan pembungkus supaya anda boleh mendedahkan fungsi penetap terpusat anda untuk ujian.

perkara yang sama perlu dilakukan pada panggilan api/pustaka pihak ketiga anda. Ia mestilah global dan tunggal supaya anda boleh menguji dengan yakin "apabila saya melakukan ini, ialah panggilan api teras/bukan teras yang dibuat dalam aplikasi". Ini dilakukan secara rutin dalam, pengalaman terhad saya, aplikasi bahagian belakang. Ia harus dilakukan dalam aplikasi bahagian hadapan juga.

Bagaimana bunyi ini? Saya pasti seseorang sudah pun melakukan ini, apakah pengalaman anda? apa yang boleh diperbaiki? Saya ingin mendengar daripada orang ramai yang ujian bahagian hadapan hanya melangkaui penyemak imbas E2E/tanpa kepala dan ujian unit mudah mati otak.

Atas ialah kandungan terperinci Pada ujian frontend yang berkesan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!