Mempertahankan Kualitas End-To-End Dengan Pengujian Visual

Pengujian adalah bagian penting dari alur kerja pengembang mana pun. Ini membantu kami untuk memastikan bahwa proyek kami akan mempertahankan kualitas tingkat tinggi, serta mencegah bug sial keluar ke alam liar.

Tetapi seringkali tes otomatis bisa sulit untuk dikelola. Di antara jumlah kode yang tak terbatas untuk memastikan Anda memberikan cakupan penuh dan menangani sifat rapuh dari pengujian front-end — di mana perubahan pemilih sederhana dapat benar-benar merusak alur kerja ujung ke ujung — terkadang terasa seperti menanjak pertarungan.

Dengan menambahkan pengujian visual otomatis , kami dapat menghilangkan pengujian yang tidak stabil tersebut, meningkatkan jalur pipa pengujian kami yang menyediakan cakupan tersebut (dan lebih banyak lagi) dengan memanfaatkan perbandingan gambar cerdas menggunakan tangkapan layar situs web atau aplikasi kami.

Sebelum kita menyelami pengujian visual, mari luangkan waktu sejenak untuk menyegarkan diri kita sendiri tentang berbagai jenis pengujian otomatis dan bagaimana mereka cocok satu sama lain. Kami kemudian akan berbicara tentang apa sebenarnya pengujian visual dan bagaimana hal itu dapat memberi Anda tingkat cakupan pengujian lain untuk proyek Anda.

Sekilas Tentang Beberapa Jenis Pengujian Otomatis

Pengujian otomatis adalah bagian yang menarik dari siklus pengembangan. Beberapa klien atau pemangku kepentingan dapat dengan jelas melihat nilai yang mereka berikan, tetapi yang lain lebih suka waktu pengembangan yang dihabiskan untuk pengembangan fitur murni.

Ini terkadang bisa berlawanan dengan intuisi, di mana tujuan pengujian otomatis adalah untuk melindungi bisnis atau mencegah tim dari harus menghabiskan waktu untuk memperbaiki bug sejak awal. Menulis tes otomatis yang solid dapat mencegah kerugian finansial yang besar! Ini pada akhirnya risiko bahwa beberapa lebih bersedia untuk mengambil daripada yang lain.

Untungnya, nilai tersebut tidak selalu sulit untuk dijual, dan ketika kami diberi waktu untuk fokus pada pengujian otomatis yang berkualitas, kami memiliki berbagai opsi tentang cara menangani pengujian tersebut seperti pengujian unit, pengujian integrasi, pengujian end-to-end. pengujian, dan pengujian visual (yang juga dapat memberikan cakupan yang diperluas untuk tiga yang pertama).

Ketika diterapkan dengan kekuatan setiap jenis tes, kami dapat menghabiskan lebih banyak waktu menulis tes yang benar-benar dapat membantu melindungi pekerjaan kami dan menyelamatkan frustrasi pelanggan kami.

Mari kita lihat seperti apa beberapa strategi pengujian ini dalam praktiknya.

Pengujian Unit

Pengujian unit berfokus pada pengujian area aplikasi yang lebih kecil dan terfokus . Ingin menguji apakah fungsi yang menghitung total pesanan setelah promosi berfungsi dengan baik? Anda ingin menulis tes unit.

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

Bagian terbaik dari unit test adalah mereka murah untuk ditulis dan tidak membutuhkan banyak waktu untuk menjalankannya. Itulah mengapa Anda akan sering melihat perusahaan menghabiskan banyak waktu untuk membangun serangkaian pengujian unit untuk menangkap bagian-bagian granular dari suatu aplikasi.

Tetapi karena pengujian terfokus itu, pengujian unit mungkin tidak mencakup bagaimana bagian-bagian yang berbeda itu bekerja bersama, di situlah kami mulai beralih ke pengujian integrasi.

Tes integrasi

Tujuan dari pengujian integrasi adalah untuk mengambil bagian-bagian yang lebih kecil dan komponen dari sebuah aplikasi dan menguji bagaimana mereka bekerja sama . Contoh umum adalah bagaimana bagian tertentu dari UI merespons interaksi yang diikuti oleh permintaan ke server atau database.

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

Sangat mungkin bahwa komponen UI kecil Anda berfungsi seperti yang diharapkan dengan sendirinya. Peristiwa sintetis Anda mungkin terpicu dengan benar pada instans onClick. Kode yang membungkus permintaan API Anda mungkin berfungsi sempurna dengan beberapa data tiruan. Tetapi mungkin ada lubang di antara kedua bagian yang bekerja bersama yang mungkin tidak ditangkap oleh unit test Anda.

Tes integrasi adalah cara yang menarik untuk menguji aplikasi Anda, tetapi Anda dapat mengambil langkah lebih jauh saat Anda ingin menguji "semua hal".

Pengujian End-To-End

Pengujian ujung ke ujung menangkap seluruh perjalanan pengguna dari ujung ke ujung untuk alur kerja yang terfokus. Misalnya, jika saya sedang membangun toko e-niaga, "jalur bahagia" (atau jalur yang diharapkan dengan hambatan paling sedikit) adalah menemukan produk, menambahkannya ke keranjang, dan membayar barang-barang tersebut. Jika saya menulis tes ujung ke ujung, saya akan menangkap seluruh proses itu, yaitu mulai dari menemukan produk di halaman daftar produk hingga membayar barang itu.

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

Bagian terbaik dari pengujian ujung ke ujung pada dasarnya adalah pengujian integrasi yang besar. Anda menangkap banyak komponen aplikasi yang berbeda termasuk cara kerja UI, bahwa API merespons dengan benar, dan bagian-bagian itu bekerja bersama.

Masalahnya adalah bahwa pengujian ujung ke ujung, dan bahkan pengujian integrasi, membutuhkan lebih banyak waktu untuk menulis dan juga membutuhkan waktu lebih lama untuk dijalankan. Jadi, bagaimana kami dapat memanfaatkan semua opsi pengujian kami dan mengumpulkan serangkaian pengujian yang akan memberikan cara yang efisien untuk mencakup aplikasi kami?

Memanfaatkan Berbagai Jenis Pengujian

Ada berbagai pola pikir yang umumnya menggambarkan berapa banyak tes dari setiap jenis Anda harus menghabiskan waktu menulis.

Mike Cohn mengemukakan konsep "piramida uji" dalam bukunya Succeeding with Agile .

Dia berpendapat bahwa Anda harus menulis lebih banyak unit test di mana mereka lebih murah untuk ditulis dan lebih cepat untuk dijalankan. Sementara diagram aslinya memberi label berbagai tes sedikit berbeda, saat Anda lebih condong ke pengujian tipe integrasi, mereka menjadi lebih lambat untuk dijalankan dan lebih mahal untuk ditulis. Meskipun pengujian tersebut berharga, Anda tidak ingin memiliki integrasi atau pengujian end-to-end sebanyak yang Anda lakukan pada pengujian unit.

Memiliki keseimbangan ini dapat membantu Anda fokus dalam menangkap bagian-bagian penting dari aplikasi, seperti logika bisnis dengan pengujian unit dan bagaimana mereka bekerja bersama dengan pengujian integrasi, tetapi Kent C. Dodds berpendapat bahwa teknologi pengujian telah mencapai titik di mana tidak ada trade-off biaya besar yang lebih lama untuk menulis tes integrasi, di situlah konsep "piala tes" masuk.

Dalam lingkungan pengembangan modern, kami memiliki banyak alat luar biasa yang kami miliki seperti Cypress, Selenium, dan Playwright yang masing-masing memberi pengembang dan insinyur QA kemampuan untuk menulis pengujian yang mudah berinteraksi dengan browser seperti Chrome dan Firefox.

Dengan Cypress, menulis tes yang mengklik tombol dapat terlihat sesederhana:

 cy.get('#my-button').click()

Itu bisa dibilang sesederhana menguji bahwa tombol tersebut bekerja dengan kejadian sintetis, jika tidak lebih sederhana. Bagian terbaiknya adalah Anda menguji cara kerja tombol itu di browser.

Terlepas dari diagram mana Anda berlangganan, pada akhirnya tujuannya adalah untuk menimbang pilihan yang berbeda antara biaya dan kecepatan untuk menentukan kecocokan yang tepat untuk aplikasi khusus Anda. Penting untuk tidak hanya mencapai 100% pada laporan liputan Anda, tetapi untuk benar-benar memastikan pengalaman yang Anda berikan kepada pengunjung berfungsi sebagaimana mestinya.

Namun, apa pun campuran pengujian yang Anda jalankan, pengujian terprogram yang hanya berinteraksi dengan dan menguji DOM (Document Object Model) ini kehilangan satu bagian besar teka-teki: bagaimana pengunjung Anda melihat aplikasi itu secara visual.

Jenis Pengujian Tradisional Apa yang Tidak Dapat Dilakukan?

Saat Anda menjalankan unit, integrasi, dan pengujian ujung ke ujung pada aplikasi Anda, semuanya memiliki satu kesamaan. Mereka semua sedang menguji kodenya.

Yang saya maksud dengan itu adalah mereka tidak menguji apa yang sebenarnya dilihat oleh pengunjung aplikasi Anda.

Jika Anda menjalankan serangkaian pengujian integrasi dan seperti contoh kami sebelumnya, menguji bahwa seseorang dapat menambahkan produk ke keranjang dan membelinya, setiap langkah, Anda akan menemukan elemen di DOM melalui kode dan mengonfirmasinya itu bekerja dengan cara yang sama.

Ini tidak menguji hal-hal seperti apakah teks pada halaman Anda dapat dibaca atau tidak. Apakah seseorang menambahkan perubahan CSS yang secara tidak sengaja melayang semua hal ke kiri dan membalikkannya?

Jenis bug ini disebut sebagai "bug visual", di mana mereka mungkin lulus semua tes Anda dengan warna terbang, tetapi ketika seseorang benar-benar melihatnya, itu tidak sepenuhnya benar atau lebih buruk, sama sekali tidak dapat digunakan.

Secara realistis, kami tidak dapat berharap untuk memberikan cakupan penuh 100% dari setiap detail antarmuka pengguna dengan pengujian tradisional. Antara jumlah status aplikasi yang tak terbatas dan fakta bahwa kami selalu menambahkan fitur baru, itu tidak skala.

Inilah yang membawa kita ke tajuk utama cerita ini: Pengujian Visual .

Apa itu Pengujian Visual?

Pengujian Visual menangkap output yang terlihat (seperti tangkapan layar) dari suatu aplikasi dan membandingkannya dengan aplikasi yang sama di waktu lain.

Ini biasanya terjadi dengan terlebih dahulu menangkap tangkapan layar garis dasar, atau contoh aplikasi yang diambil sebelumnya dengan hasil yang diharapkan, dan membandingkan setiap pengujian baru dengan garis dasar itu.

Tetapi ketika proyek Anda dikembangkan, banyak hal berubah. Seiring berjalannya waktu, garis dasar itu akan diperbarui bersama dengan aplikasi Anda saat Anda menyetujui perbedaan visual baru sebagai perubahan yang diterima.

Jenis Pengujian Visual

Hal yang menarik tentang Pengujian Visual adalah ada berbagai cara untuk menangani ini.

Salah satu pendekatan untuk menguji secara visual adalah dengan menggunakan perbandingan piksel demi piksel di mana kerangka pengujian akan menandai secara harfiah setiap perbedaan yang dilihatnya antara dua gambar. Sementara perbandingan tersebut memberikan entry-level ke dalam pengujian visual, itu cenderung tidak stabil dan dapat menyebabkan banyak kesalahan positif.

Seperti yang dapat Anda bayangkan, saat bekerja dengan web, segala sesuatunya cenderung sedikit berbeda antara pemuatan halaman dan pembaruan browser. Jika browser merender halaman sebesar 1 piksel karena perubahan rendering, kursor teks Anda ditampilkan, atau "hanya karena", penerapan Anda mungkin diblokir karena pengujian yang gagal ini.

Pengujian Anda juga rentan terhadap kegagalan saat menangani konten dinamis. Misalnya, jika Anda menjalankan pengujian visual piksel demi piksel setiap hari di beranda situs ini, Majalah Smashing , Anda akan mendapatkan banyak pengujian yang gagal karena mereka menghasilkan lebih banyak konten.

Cara yang lebih baik untuk menangani pengujian visual adalah dengan memanfaatkan teknologi seperti AI di mana setiap kali pengujian dijalankan, kerangka pengujian secara cerdas melihat tangkapan layar yang diambil dibandingkan dengan baseline.

Itu dapat mendeteksi bahwa dua tangkapan berbeda atau bahkan mendeteksi jika itu adalah perubahan konten yang bertentangan dengan perubahan tata letak. Itu tidak akan menandai pengujian itu sebagai gagal jika sesuatu tidak benar-benar berubah dan Anda bahkan dapat menambahkan aturan untuk mengabaikan wilayah dinamis aplikasi yang mungkin berubah karena konten itu.

Dimana Pengujian Visual Membantu

Pengujian visual berkembang pesat karena mampu menangkap status aplikasi saat ini seperti yang dilihat pelanggan Anda. Ini membuatnya menarik untuk aplikasi apa pun yang akan membuat manusia nyata berinteraksi dengannya.

Saat menangkap snapshot itu, ia menyediakan cakupan banyak bagian dari aplikasi itu, bukan hanya satu komponen granular yang Anda tulis untuk pengujian. Itu akhirnya menangkap konteks di sekitar komponen itu, yang mengarah ke cakupan yang lebih luas.

Ini menjadi cara yang bagus untuk menyediakan cakupan yang luas dengan overhead yang rendah . Kembali ke piramida uji atau piala uji, kami sebenarnya dapat memberikan cakupan yang komprehensif di atas semua pengujian kami yang lain.

Bagaimana Cara Kerja Pengujian Visual?

Intinya sederhana — membandingkan dua gambar satu sama lain dan mencari perbedaannya — tetapi itu sedikit lebih terlibat dari itu.

Perbandingan Gambar

Saat menerapkan pengujian visual, tujuannya adalah untuk menyediakan cakupan untuk alur kerja kritis yang dapat menangkap bagaimana orang yang sebenarnya menggunakan aplikasi. Itu sering kali mencakup layar pertama yang mungkin dilihat seseorang, tetapi biasanya itu bukan satu-satunya layar yang mereka lihat.

Sama seperti membuat strategi untuk menjalankan pengujian tradisional, Anda ingin memastikan bahwa Anda mencari interaksi nyata yang berakhir dengan hasil nyata di UI, seperti menambahkan item ke keranjang belanja atau menambahkan item favorit ke daftar keinginan Anda.

Dengan mengingat hal itu, Anda pasti ingin mengambil tangkapan layar di setiap langkah. Misalnya, jika Anda menguji toko online, Anda mungkin ingin menambahkan langkah-langkah berikut:

• Daftar produk yang dimuat pada halaman;
• Halaman produk setelah memilih satu produk;
• UI keranjang di halaman setelah menambahkan produk ke keranjang itu;
• Halaman keranjang setelah menavigasi ke keranjang;
• UI pembayaran dan pengiriman setelah memasuki alur pembayaran;
• Halaman tanda terima setelah pembelian berhasil.

Ini akan menangkap hasil dari semua interaksi saat seseorang berjalan melalui toko online Anda, di mana Anda dapat memverifikasi bahwa tidak hanya berfungsi secara fungsional dari perspektif kode, tetapi orang tersebut benar-benar dapat menggunakan aplikasi Anda tanpa gangguan visual.

Bit Teknis

Saat Anda membuat tangkapan layar perencanaan, Anda memerlukan mekanisme untuk mengotomatiskan tugas-tugas tersebut. Sesuatu yang dapat berinteraksi dengan browser berdasarkan serangkaian tugas.

Di sinilah kerangka kerja otomatisasi browser populer seperti Selenium, Cypress dan Playwright masuk, di mana kerangka kerja pengujian tersebut memanfaatkan API browser untuk menjalankan perintah Anda, menemukan dan mengklik hal-hal seperti yang dilakukan manusia, di mana Anda kemudian akan memberi tahu kerangka pengujian visual kapan harus menangkap status UI secara visual.

Dalam kasus Cypress dan Applitools, Cypress akan menavigasi melalui setiap halaman, di mana kemudian Applitools SDK akan mengekstrak snapshot DOM, dan mengirim snapshot itu ke awan Applitools, di mana akhirnya akan menghasilkan screenshot untuk perbandingan.

Pada saat itu, tergantung pada platform pengujian visual, Anda akan mendapatkan serangkaian hasil dalam bentuk perbedaan yang disorot atau tanda centang hijau yang bagus jika semuanya terlihat bagus.

Integrasi Dengan Kerangka Pengujian yang Ada

Seperti integrasi Cypress dan Applitools di atas, integrasi biasanya memiliki gesekan yang rendah. Banyak platform pengujian visual yang tersedia dapat berintegrasi langsung ke dalam kerangka pengujian yang ada, sebagian besar hanya bergantung pada SDK mana yang tersedia.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

Ini berarti Anda biasanya tidak perlu sepenuhnya menulis ulang rangkaian pengujian untuk memperkuat pengujian dan mendapatkan cakupan visual; Anda dapat menambahkan pos pemeriksaan tersebut ke tes yang sudah Anda miliki.

Mengotomatiskan Tes

Untungnya, otomatisasi pengembangan dan tugas terkait pengujian telah matang dengan cepat, memberikan banyak opsi hebat tentang bagaimana kami dapat mengotomatiskan pengujian kami.

Solusi CI/CD tradisional seperti Jenkins atau Travis CI memungkinkan Anda menjalankan pengujian di lingkungan mereka tepat di samping jalur integrasi dan penerapan lainnya. Relatif baru dalam ruang otomatisasi adalah alat seperti GitHub Actions, di mana mereka menyediakan mekanisme yang mirip dengan lingkungan CI/CD tradisional, tetapi tepat di dalam repo GitHub Anda yang sudah ada. Ini membuatnya menjadi kemenangan yang mudah ketika mencoba menjalankan pengujian dan tugas kode lainnya secara otomatis, di mana Anda tidak memerlukan sistem yang sama sekali baru tetapi menggunakan alat yang ada.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

Namun terlepas dari lingkungan yang Anda gunakan, pada akhirnya Anda tunduk pada persyaratan kerangka pengujian. Cypress bekerja dengan sangat mulus di mana pun Anda dapat menginstal Node.js, yang cukup umum akhir-akhir ini, selama Anda memiliki akses ke browser tanpa kepala seperti Electron atau Chrome. Orang lain mungkin memerlukan sedikit lingkungan ekstra, tetapi pada saat itu, Anda biasanya dapat membuat perancah lingkungan itu seperti yang Anda inginkan, menciptakan kondisi yang Anda perlukan untuk menjalankan pengujian Anda.

Apa Manfaat Pengujian Visual?

Pengujian visual akan memberikan berbagai manfaat seperti beberapa yang telah kita bahas, tetapi ini sangat membantu semua pemangku kepentingan termasuk eksekutif, manajer produk, pengembang, desainer, dan semua orang dalam tim.

Misalnya, untuk CEO atau Manajer Produk, Anda mendapatkan keyakinan bahwa cakupan pengujian Anda benar-benar menangkap penggunaan di dunia nyata . Untuk tim pengembangan, Anda mendapatkan keyakinan yang sama bahwa setiap kali Anda membuat perubahan, Anda akan mendapatkan umpan balik langsung, menghilangkan faktor ketakutan yang terlibat ketika mencoba untuk bergerak cepat. Tetapi ada juga banyak manfaat praktis.

Lebih Sedikit Kode Untuk Dipertahankan

Saat berintegrasi dengan platform pengujian visual, sebagian besar kode Anda akan berkisar pada dua hal: interaksi dan tangkapan layar.

Interaksi pada dasarnya menavigasi melalui aplikasi, menemukan halaman atau aliran pengguna apa yang ingin Anda tangkap. Terlepas dari bagaimana Anda menguji, Anda mungkin perlu mempertahankan ini dalam satu atau lain bentuk.

Tangkapan layar, di sisi lain, akan mencakup semua pernyataan yang biasanya Anda tulis dalam ujian. Dengan membandingkan setiap tangkapan layar dengan garis dasar, Anda secara otomatis memastikan bahwa setiap komponen proyek Anda berfungsi persis seperti yang diinginkan.

Tes Kurang Rapuh

Dan dengan menggunakan tangkapan layar tersebut sebagai mekanisme penegasan Anda, pengujian Anda akan menjadi tidak terlalu rapuh dan rapuh.

Jika Anda menulis pernyataan terhadap bagian tertentu dari DOM, seperti menggunakan ID atau pemilih yang dibuat secara otomatis, Anda mempertaruhkan pengujian putus dengan perubahan apa pun pada komponen itu.

Dengan ID, seseorang mungkin secara tidak sengaja menghapus atau mengubahnya. Mungkin Anda mengira itu hanya untuk tujuan fungsional dan memperbaruinya saat mengerjakan ulang, yang akhirnya melanggar tes (terjadi pada saya!).

Atau jika Anda menggunakan penyeleksi umum, baik yang dibuat secara otomatis atau tidak, penyeleksi tersebut cenderung sangat spesifik saat Anda menguji bagian aplikasi yang sangat spesifik . Jika Anda akhirnya membuat beberapa HTML atau memindahkan sesuatu di dalam kode sedikit, bahkan jika Anda tidak mengubah tampilannya secara visual, itu bisa merusak tes itu.

Menguji Apa yang Sebenarnya Digunakan Orang

Berbicara tentang pengujian tampilan visual, saat pengujian visual, Anda menguji apa yang sebenarnya dilihat pengunjung atau pelanggan Anda.

Menggunakan HTML semantik yang tepat tidak secara otomatis membuat proyek Anda dapat digunakan. Perubahan CSS kecil (seperti z-index) dapat sepenuhnya mengubah kegunaan dan tampilan sesuatu.

Dengan mengambil tangkapan layar dan membandingkan keadaan aplikasi yang sebenarnya melalui interaksi alur pengguna, Anda dapat memastikan bahwa aplikasi Anda berfungsi secara fungsional serta memastikannya dapat digunakan oleh lebih dari sekadar robot otomatisasi.

Bacaan yang disarankan : Mengelola Indeks Z CSS di Proyek Besar

Menguji Hal-hal yang Tidak Anda Pikirkan Untuk Diuji

Anda juga mendapatkan cakupan dari berbagai bagian aplikasi yang bahkan tidak terpikirkan untuk Anda uji.

Pertimbangkan daftar tes yang Anda miliki di suite Anda, itu adalah tes yang Anda pikirkan untuk ditulis atau ditulis karena sebelumnya Anda menemukan bug. Bagaimana dengan sisa aplikasi?

Tangkapan layar itu akan menangkap lebih banyak detail dan konteks yang mungkin tidak disertakan oleh pengujian Anda yang lain.

Apa yang Tidak Dicakup oleh Pengujian Visual?

Tetapi pengujian visual tidak dimaksudkan sebagai solusi akhir untuk menggantikan seluruh rangkaian pengujian Anda. Seperti jenis tes lainnya, tes itu harus hidup berdampingan, mengisi kekosongan yang lain dan pada akhirnya memberikan cakupan yang lebih bermakna.

Menguji Logika Bisnis Berbasis Data

Saat Anda menjalankan tes visual, Anda mungkin dapat menangkap beberapa aspek logika bisnis Anda, seperti memastikan ketika seseorang menambahkan item ke troli, bahwa matematika diperiksa, tetapi toko online Anda kemungkinan memiliki variasi yang lebih luas. dari hanya satu produk itu.

Tetap penting untuk menangkap logika bisnis yang kompleks itu dengan pengujian unit, memastikan Anda menangkap kasus penggunaan yang berbeda seperti bagaimana berbagai diskon memengaruhi total itu.

Pengujian API Komprehensif

Saat berurusan dengan API, Anda dapat memikirkan pengujian visual seperti pengujian integrasi. Kami dapat menguji bahwa saat berinteraksi dengan browser, logika permintaan kami berfungsi seperti yang diharapkan. Tapi itu tidak memberikan pandangan yang komprehensif tentang bagaimana API itu berfungsi.

Mirip dengan logika bisnis, API Anda tetap harus didukung oleh serangkaian pengujian yang akan memastikannya berfungsi seperti yang diharapkan seperti pengujian unit atau health check.

Memulai Pengujian Visual

Sebagai alat lain di ikat pinggang kami, pengujian visual benar-benar dapat membantu memberikan tingkat cakupan lain yang membantu kami mempertahankan tingkat kualitas yang tinggi untuk aplikasi kami, tetapi dari mana kami memulai?

Menyesuaikan dengan Siklus Hidup Pengembangan

Karena pengujian visual membantu mencapai tujuan semua pemangku kepentingan, ini benar-benar dapat diterapkan di bagian mana pun dari siklus hidup pengembangan.

Misalnya, pengujian tradisional hanya digunakan untuk memvalidasi bahwa kode berfungsi sebagaimana dimaksud, tetapi kita juga dapat menggunakan pengujian visual untuk handoff desain dan kolaborasi UX . Perancang dalam tim dapat memasang maket mereka sebagai dasar dan dengan mudah menggunakannya untuk membandingkan pengalaman yang sebenarnya.

Namun dari perspektif kode, pengujian visual dapat berkembang pesat di lingkungan otomatis seperti menjalankan pemeriksaan pada permintaan tarik, pada lingkungan staging sebelum penerapan, dan memastikan produksi terlihat bagus setelah penerapan.

Anda bahkan dapat menjalankan pengujian visual pada cron, menggantikan aktivitas sintetis pemeriksaan kesehatan, yang biasanya tidak stabil dan tidak pernah benar-benar memberi tahu Anda status aplikasi Anda.

Untungnya ada banyak pilihan untuk layanan apa yang Anda gunakan, tetapi juga titik integrasi untuk menggunakan layanan tersebut.

Solusi yang Tersedia Untuk Pengujian Visual

Menentukan solusi yang akan digunakan bergantung pada pemilihan pustaka atau layanan yang akan Anda gunakan untuk menjalankan pengujian. Seperti yang telah kita bahas sebelumnya, pembeda terbesar adalah jenis pengujian visual yang disediakan oleh layanan ini.

Banyak platform menggunakan pengujian visual piksel demi piksel untuk melakukan pemeriksaan. Ini termasuk alat seperti Percy dan Chromatic yang akan menandai perubahan di antara dua tangkapan layar.

Kemudian Anda memiliki pengujian visual bertenaga AI, di mana Applitools benar-benar satu-satunya layanan yang saat ini menyediakan kemampuan itu. Alih-alih hanya memeriksa gambar piksel demi piksel, Applitools dengan cerdas membandingkan gambar untuk menghindari tes tidak stabil atau positif palsu , memberikan deteksi perubahan yang berarti.

Terlepas dari solusinya, pada akhirnya Anda harus mengintegrasikannya ke dalam lingkungan pengembangan Anda, baik Anda memulai dari awal atau menambahkannya ke kerangka kerja pengujian yang ada.

Mengintegrasikan Pengujian Visual

Saat mengintegrasikan platform pengujian visual pilihan Anda, Anda memiliki opsi untuk memulai dari awal atau rute yang lebih mudah untuk diintegrasikan ke dalam kerangka pengujian yang ada. Alat seperti Applitools mempermudah ini, di mana berbagai macam SDK yang didukung membantu memudahkan untuk masuk ke alur kerja yang ada.

Contoh bagusnya adalah jika Anda sudah menyiapkan dan menjalankan dengan Cypress:

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

Jika Anda sudah melakukan pengujian terprogram, Anda cukup melapisi pengujian visual untuk memberikan lapisan cakupan lainnya.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

Dan beberapa SDK membuatnya lebih mudah, di mana jika Anda sudah menjalankan perpustakaan Buku Cerita, yang perlu Anda lakukan hanyalah menginstal paket dengan npm dan menjalankan perintah sederhana, maka Anda memiliki cakupan lengkap dari semua komponen Anda.

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

Pada akhirnya, pertanyaan terbesar adalah kerangka pengujian apa yang ingin Anda gunakan dan apakah layanan yang ingin Anda gunakan mendukung kerangka kerja itu.

Penggunaan Kreatif Pengujian Visual

Di luar mendapatkan tingkat cakupan pengujian lain untuk aplikasi Anda, ada berbagai cara lain yang dapat Anda manfaatkan dari pengujian visual.

• Pemantauan Waktu Aktif
  Jalankan pengujian visual yang bermakna secara teratur alih-alih pemantauan waktu aktif biasa dengan peristiwa sintetis yang rapuh.
• Kolaborasi Desain/UX
  Dari handoff hingga masalah kegunaan, gunakan pengujian visual untuk memberi seluruh tim media untuk berkolaborasi.
• Pengujian Aksesibilitas
  Catat masalah utama yang dapat membatasi aksesibilitas aplikasi Anda.
• Cuplikan Historis
  Menjalankan pengujian visual secara berkala dapat membantu Anda mengambil snapshot, dengan mudah memberi Anda cara untuk merujuk status proyek yang lebih lama.
• Pengujian Lokalisasi
  Dengan pengujian visual berbasis AI yang mampu mendeteksi perubahan konten, Anda memiliki kemampuan untuk memastikan semuanya terlihat dan berfungsi seperti yang diharapkan, apa pun bahasanya. Bonus: Anda dapat mengurangi overhead saat mencoba membandingkan berbagai versi bahasa tertentu.

Dengan menambahkan elemen visual ke pengujian, Anda mendapatkan lebih banyak opsi untuk menambahkan cara yang berarti guna mempertahankan tingkat kualitas yang tinggi untuk aplikasi Anda.