cypress 🚀 - maks 1 situs... mendukung mengunjungi beberapa superdomain dalam satu pengujian | bleepcoder.com (2024)

Ya, itu bisa dilakukan. Pertanyaan cepat - apakah ada alasan Anda memerlukan browser untuk memuat 500 domain berbeda dan mengklik tombol?

Bukankah akan jauh lebih mudah untuk menggunakan cy.request atau cara program lain untuk mencapai ini?

Misalnya, apa yang dilakukan mengklik tombol? Mengirim permintaan HTTP adalah tebakan saya. Jadi alih-alih menggunakan UI, cukup kirim permintaan HTTP secara langsung menggunakan cy.request . Hasil yang sama, 100x lebih cepat, dan tidak ada masalah domain.

Setiap informasi tambahan tentang kasus penggunaan Anda akan sangat membantu.

Langsung masuk untuk mengatakan bahwa saya memiliki kasus penggunaan di mana saya perlu memuat beberapa situs dalam pengujian yang sama (bukan 500, 2 akan dilakukan untuk pengujian).

Saya sedang menguji ekstensi browser yang akan menampilkan modal (melalui skrip konten) di beberapa situs yang dapat Anda daftar putih di pengaturannya. Ekstensi menggunakan penghitung waktu global (melalui tab latar belakangnya) untuk menyinkronkan perilaku ekstensi di berbagai situs/tab/klik tautan/penyegaran (ini terus menghitung mundur saat Anda menelusuri berbagai situs yang masuk daftar putih, antara lain). Karena batasan ini, saya tidak dapat menguji apakah sinkronisasi berfungsi ketika situs yang saya kunjungi berada di domain yang berbeda.

Saya tidak bisa hanya membuat cy.request karena saya membutuhkan Chrome untuk memuat halaman, lalu memuat skrip konten ekstensi di atasnya, lalu menegaskan bahwa skrip konten menunjukkan modal dan kontennya koheren dengan sinkronisasi tab silang saya harapkan terjadi.

Bukankah akan jauh lebih mudah untuk menggunakan cy.request atau cara program lain untuk mencapai ini?

Bagi saya masalahnya adalah _more_ bekerja untuk mensimulasikan permintaan daripada meminta Cypress mengisi formulir.

Itu dan itu menyimpang terlalu jauh dari aliran Pengguna yang akan dialami pengguna saya.

@alovato88 jika Anda beralih menggunakan cy.request untuk masuk secara terprogram untuk menerima token Anda, semuanya akan berfungsi. Kami memiliki beberapa resep yang menampilkan ini.

@MaxwellGBrown kami telah melewati lubang kelinci ini berkali-kali dengan banyak umpan balik pengguna yang berbeda dan jawabannya selalu sama - Anda dapat menguji halaman login Anda secara terpisah dari aplikasi utama sekali, dan kemudian menggunakan cy.request untuk secara terprogram menggunakannya setelah itu. Anda mendapatkan manfaat dari "benar-benar mengujinya seperti pengguna" dan kemudian setelah selesai, Anda tidak mendapatkan manfaat lebih lanjut.

Cukup kunjungi domain LAINNYA dalam pengujian dan masuk. Anda bahkan dapat menghentikan permintaan jaringan jika Anda ingin mencegah server pihak ke-3 mengarahkan Anda. Setelah Anda melakukannya, gunakan cy.request untuk menerima token secara terprogram dan kemudian MULAI dengan token di tangan mengunjungi aplikasi Anda yang sebenarnya. Cukup atur token secara langsung di cookie atau penyimpanan lokal dan aplikasi Anda akan "mulai" masuk.

Ada banyak masalah lain di sini di mana saya telah berkomentar dengan memberikan pendekatan dan solusi berbeda yang mungkin berguna bagi Anda semua.

Praktik terbaik kami mencakup ini cukup mendalam, dan saya bahkan telah memberikan ceramah tentang subjek ini dan memberikan contoh dunia nyata tentang bagaimana mendekati masalah ini.

• https://on.cypress.io/best-practices#Organizing -Tests-Logging-In-Controlling-State
• https://on.cypress.io/best-practices#Visiting -external-sites

@ejoubaud Anda dapat melakukan ini di Cypress - cukup kunjungi domain dalam tes yang berbeda, bukan tes yang sama. Selama Anda tidak mengunjungi dua domain super berbeda dalam satu pengujian, semuanya akan berfungsi. Kunjungi satu domain super, uji ekstensi Anda, lalu dalam pengujian terpisah kunjungi domain lain dan uji ekstensi Anda di sana.

https://on.cypress.io/recipes

Saya pikir saya memiliki kasus penggunaan yang baik untuk ini. Kami bermigrasi dari aplikasi Ruby on Rails monolitik, ke layanan mikro di back-end dan front-end yang berbeda tipe pengguna. Front-end baru kami adalah React SPA, dan salah satunya terlalu besar untuk diganti sekaligus, jadi untuk beberapa rute aplikasi kami hanya menampilkan halaman asli dalam iframe sedangkan untuk yang lain kami menggunakan komponen React untuk merender rute tersebut.

Saat ini saya tidak dapat menulis tes yang melatih yang baru dan yang lama secara bersamaan. Saat ini saya sedang mengerjakan ini dengan meletakkan setiap tes di filenya sendiri, tetapi ini jauh dari ideal.

Saya ingin sekali bisa mengunjungi banyak domain. Kasus penggunaan saya sedang menguji integrasi antara situs front end dan admin backend. Tentu saja ada cara untuk tidak mengunjungi banyak domain, namun secara lokal mereka hanya berjalan di port yang berbeda (3000, dan 3001). Pasti ada pekerjaan di sekitar:

1. Menggunakan cy.request . Saya bisa melakukan ini namun saya akan membuat permintaan ke api backend ke pengguna seed dan membuat perubahan. Jika bentuk API berubah sekarang, suite integrasi saya berubah seperti halnya kode aplikasi saya. Sepertinya kopling aneh yang tidak ingin saya miliki
2. Menyiapkan Apache lokal untuk meneruskan subdomain ke port. Lagi. sangat mungkin, namun pengaturan mesin dev yang lebih rumit adalah sesuatu yang saya lebih suka hindari, terutama karena perbedaannya hanya pada nomor port dan bukan pada nama host.

Ini adalah pemblokir mutlak untuk klien saya saat ini. Mereka telah membangun solusi yang mengintegrasikan beberapa sistem SaaS termasuk Salesforce, dan harus mampu menguji efek samping dalam sistem terintegrasi. Misalnya, pendaftaran di front-end Web menyebabkan prospek dibuat di Salesforce.

Kami juga harus meninggalkan Cypress untuk Selenium, meskipun antusiasme _signifikan_ untuk Cypress, jika kasus penggunaan ini tidak dapat diatasi.

_Update:_ mungkin tidak ... kami selanjutnya dapat menguji status pada sistem SaaS dalam konteks kedua, dan menyetel ulang dalam konteks ketiga. Sesuatu dari hack sekalipun.

Karena ini belum ditangani dengan benar selama hampir satu tahun, saya akan menyarankan (hanya pendapat saya) orang-orang yang berpikir Cypress terlalu membatasi untuk hanya menggunakan Dalang secara langsung (dengan kerangka kerja seperti Jest jika diperlukan).

Hasil yang sama tetapi dengan alat yang dipelihara dan ditingkatkan secara aktif.

Keterbatasan ini juga menjadi penghambat bagi kami.

Saya pikir saya mungkin bisa mengatasi keterbatasan ini dengan menjadi sedikit kreatif. Saya mencoba solusi berikut tanpa hasil:

Upaya solusi 1 - Gunakan proxy khusus untuk menghapus header keamanan
Sebagai permulaan saya menetapkan chromeWebSecurity ke false .
Ini tidak membantu saya karena aplikasi eksternal yang ingin saya gunakan mengirim kembali header x-frame-options . Saya menemukan bahwa Cypress menghapus ini untuk Application Under Test (AUT), tetapi tidak untuk aplikasi eksternal.

Untuk mengatasi ini, saya membuat proxy yang akan menghapus header ini, dan meneruskan proxy ini ke Cypress menggunakan variabel lingkungan:

const fs = require('fs');const hoxy = require('hoxy');const hostname = 'localhost';const port = process.argv[2];createProxy(hostname, port);console.log(`Started proxy on ${hostname}:${port}`);function createProxy(hostname, port) { const proxy = hoxy .createServer({ certAuthority: { key: fs.readFileSync(`${__dirname}/ca/selfsigned-ca.key.pem`), cert: fs.readFileSync(`${__dirname}/ca/selfsigned-ca.crt.pem`) } }) .listen(port, hostname); proxy.intercept({ phase: 'response' }, removeSecurityHeaders);}function removeSecurityHeaders(request, response) { console.log(request.fullUrl()); delete response.headers['x-frame-options'];}

Mengirimkannya ke Cypress: HTTPS_PROXY=http://localhost:8080 HTTP_PROXY=http://localhost:8080 https_proxy=http://localhost:8080 http_proxy=http://localhost:8080 cypress open .

Permintaan yang melewati proxy saya, tetapi masih tidak berhasil. Setelah beberapa saat saya menemukan bahwa hanya permintaan untuk AUT yang melewati proxy.
Kemudian saya juga menemukan bahwa Cypress menggunakan proxy itu sendiri, jadi menggabungkan ini dengan proxy khusus mungkin tidak akan berfungsi dengan baik.

Upaya solusi 2 - Muat ekstensi Chrome untuk menghapus header keamanan
Upaya kedua saya adalah memuat ekstensi Chrome yang akan menghapus header jahat itu .
Saya menambahkan chrome-ext-downloader ke package.json saya sehingga ekstensi akan diunduh.

{ "scripts": { "download-extension": "ced gleekbfjekiniecknbkamfmkohkpodhe extensions/ignore-x-frame-headers" }, "dependencies": { "chrome-ext-downloader": "^1.0.4", }}

Dan memuat ekstensi melalui plugins/index.js

const path = require('path');module.exports = (on, config) => { on('before:browser:launch', (browser = {}, args) => { console.log(config, browser, args); if (browser.name === 'chrome') { const ignoreXFrameHeadersExtension = path.join(__dirname, '../extensions/ignore-x-frame-headers'); args.push(args.push(`--load-extension=${ignoreXFrameHeadersExtension}`)); } return args; });};

Dengan ini halaman eksternal dimuat. Namun, Cypress tidak bekerja pada halaman itu. Rupanya Cypress menggunakan proxy untuk menyuntikkan dirinya ke halaman.

Kesimpulan
Dengan versi Cypress saat ini, tampaknya mustahil untuk membuatnya bekerja dengan beberapa domain super. Kreativitas tampaknya tidak membantu.
Untuk mengatasi ini, itu harus diselesaikan di Cypress itu sendiri.

Sekarang mari kita bahas ini.
Saya akan mengatakan pasti ada kasus penggunaan uji e2e yang memerlukan ini.
Memang, dalam beberapa kasus seseorang dapat menggunakan cy.request untuk mencapai hasil yang sama seperti berinteraksi dengan domain tambahan.
Saat Anda menguji SPA, Anda bisa menggunakan solusi cy.request , atau hanya mengejek keseluruhan backend.

Hal yang berbeda ketika Anda ingin menguji integrasi antara aplikasi yang berbeda. Jika pengujian integrasi tersebut adalah fokus utama pengujian Anda, Anda memerlukan dukungan untuk beberapa domain super. Seringkali integrasi tersebut menyertakan aliran yang lebih rumit seperti: application1 => third party application1 => application2 => third party application 2 => application1 .

Sekarang orang dapat berargumen bahwa Cypress tidak dimaksudkan untuk kasus penggunaan seperti ini. Apalagi jika ada keterbatasan teknis yang hampir mustahil untuk diatasi.

Apa yang saya lewatkan dalam diskusi ini adalah penjelasan tentang apa batasan teknis ini. Mengapa Cypress saat ini hanya mendukung satu domain super? Apa yang dibutuhkan untuk mendukung banyak? Apakah penerapan itu membuat Cypress jauh lebih kompleks? Atau apakah itu, hanya banyak pekerjaan?

Terkait:

• Masalah yang saya buka ketika saya mengerjakan ini. .
• Masalah pada dokumen, yang meminta dokumentasi arsitektur .

Inilah solusi peretasan:

Cypress.Commands.add('forceVisit', url => { cy.get('body').then(body$ => { const appWindow = body$[0].ownerDocument.defaultView; const appIframe = appWindow.parent.document.querySelector('iframe'); // We return a promise here because we don't want to // continue from this command until the new page is // loaded. return new Promise(resolve => { appIframe.onload = () => resolve(); appWindow.location = url; }); });});

Hai @suchipi , ini sepertinya solusi yang menjanjikan! Tapi sayangnya masalah x-frame-options masih tetap ada bagi kami...

Refused to display 'https://*****' in a frame because it set 'X-Frame-Options' to 'deny'.

Menguji ini dengan harapan itu akan berhasil, ini sudah merupakan peningkatan karena tampaknya memuat halaman yang dijanjikan tetapi kemudian:

Menolak untuk menampilkan 'https:// * *'' dalam bingkai karena menyetel 'X-Frame-Options' ke 'sameorigin'.

Akan menonton posting ini untuk pembaruan.

Biarkan saya menyajikan kasus penggunaan yang saya perlukan untuk mengunjungi 2 domain, untuk membawa 2 sen saya tentang masalah ini.

• Saya memiliki aplikasi back-office (misalnya localhost:8000 ), di mana orang-orang dari staf kami perlu memvalidasi identitas pengguna;
• Saya memiliki aplikasi yang menghadap pengguna (misalnya localhost:8001 ), di mana pengguna kami dapat menandatangani kontrak secara digital setelah mereka diautentikasi.

Ini adalah versi TL;DR dari alur kerja orientasi kami. Ini sangat kolaboratif antara pengguna kami dan back-office kami, dan tidak masuk akal untuk menguji satu tanpa yang lain.

Memprogram ini melalui cy.request akan memakan biaya lebih banyak dalam hal pemeliharaan daripada apa yang kita lakukan sekarang yaitu membuat beberapa spesifikasi yang disebut something-a , something-b , yang seharusnya dijalankan satu per satu lain. Setiap langkah yang diperlukan untuk mengganti aplikasi apa yang sedang digunakan membutuhkan subspesifikasi baru.

Mungkin hal-hal yang berjalan pada localhost dengan nomor port yang berbeda dapat dianggap sebagai domain yang sama untuk membuat sebagian besar pengembang dari utas ini senang? (yaitu kita keluar dari argumen "pihak ketiga")

Sebagai catatan, kami mencoba menggunakan subdomain untuk mengatasi hal ini.

Saya memiliki ini di cypress.json saya

{ "baseUrl": "https://my-website.com", "chromeWebSecurity": false}

tapi saya masih mendapatkan kesalahan ini:

CypressError: Cypress mendeteksi kesalahan asal silang yang terjadi pada pemuatan halaman:

Memblokir bingkai dengan Asal " https://my-website.com " agar tidak mengakses bingkai lintas-Asal.

Sebelum halaman dimuat, Anda terikat dengan kebijakan Asal:

https://my-other-website.com

Kesalahan lintas asal terjadi saat aplikasi Anda menavigasi ke superdomain baru yang tidak coco*k dengan kebijakan asal di atas.

Ini biasanya terjadi dalam salah satu dari tiga cara:

1. Anda mengklik yang mengarahkan Anda keluar dari aplikasi Anda
2. Anda mengirimkan formulir dan server Anda mengarahkan Anda keluar dari aplikasi Anda
3. Anda menggunakan pengalihan javascript ke halaman di luar aplikasi Anda

Cypress tidak mengizinkan Anda mengubah superdomain dalam satu pengujian.

Anda mungkin perlu menyusun ulang beberapa kode pengujian untuk menghindari masalah ini.

Atau Anda juga dapat menonaktifkan Keamanan Web Chrome yang akan menonaktifkan pembatasan ini dengan menyetel { chromeWebSecurity: false } di file 'cypress.json' Anda.

https://on.cypress.io/cross-Origin-violation

Adakah ide mengapa menonaktifkan chromeWebSecurity secara eksplisit tidak berfungsi?

Apakah ada alasan mengapa cypress menyarankan untuk mengubah properti konfigurasi ini tetapi tidak berhasil?

Solusi saya saat ini adalah membuat tes terpisah mengunjungi domain yang berbeda. Ini berfungsi karena selama dev saya memiliki server dummy yang mengikuti permintaan yang dibuat dari asal yang berbeda.

describe("Do stuff on one site then visit another and check it worked", () => { it("Can open the first site and do some things", () => { cy.visit("localhost:8080"); // do stuff that sends data to a dev server running on another port on localhost }); it("Can see the results in the other place", () => { cy.visit("localhost:8888"); // validate my things went good });});

Nama dan deskripsi tes sengaja tidak jelas.

Ini bukan praktik terbaik karena pengujian saya harus dijalankan secara berurutan dan bergantung pada yang sebelumnya, tetapi ini membantu saya menguji alur kerja saya dengan lebih baik.

Halo!

Saya harap Anda mengalami hari yang indah!

Sebagai pelanggan yang membayar, kami berharap ini akan segera diperbaiki. Kami sangat membutuhkan ini.

Saya juga pendukung fitur ini. sem*ntara itu bagaimana cara menggunakan cy.request untuk url dinamis?
Aplikasi kami membuat alur kerja yaitu /workflow/3479 <-- Angka ini dinamis. Setelah pengiriman formulir, ia menambahkan /task/968 <-- Ini tetap sama selama jenis alur kerja yang sama dipilih dan dibuat. Url akhir yang kami miliki adalah seperti /workflow/3467/task/968. Kami memiliki dedikasi server pengujian yang terbatas, jadi butuh 3 menit untuk mengirimkan formulir, dan itu menyebalkan jika terkena kesalahan CORS. Saya menonaktifkan keamanan web dan aplikasi mogok tanpa pesan untuk konsol. Itu hanya mengatakan "chrome- error://chromewebdata/ " di runner. Saya rasa ini karena SSO internal kami, dan saya akan mencoba menerapkan apa yang disebutkan dalam resep sso. Masalahnya bagi saya adalah saya tidak teknis seperti yang saya inginkan, dan itu akan memakan waktu lama bagi saya untuk mengimplementasikan ini, jika saya bisa. Yang mengatakan, bagi saya pribadi atau mungkin orang yang tidak terlalu teknis, akan lebih baik untuk beralih ke domain berikutnya dan melanjutkan pengujian saya. Saat ini, saya telah menghabiskan lebih banyak waktu daripada yang saya pedulikan untuk mencoba menyiasatinya. Saya juga ingin melihat tes e2e yang sebenarnya. Saya sangat suka cypress lebih dari selenium. Kami saat ini menggunakan TestCafe, yang sekilas tampak lebih rumit daripada pengujian yang seharusnya. Saya berusaha sangat keras untuk mendorong organisasi kami untuk sepenuhnya menggunakan cypress karena sejauh ini ini adalah alat paling keren yang pernah saya lihat, tetapi menerapkan sesuatu seperti ini pasti akan memberikan dorongan ekstra untuk mengadopsi Cypress.

Sunting: Kami juga memiliki token penyegaran tambahan yang memperbarui dirinya sendiri setiap 2 menit, jadi saya tidak yakin apakah bahkan menyetel token dalam pengalihan seperti yang ditunjukkan dalam resep akan berhasil.
🙏

cemara 3.2.0
Windows 10
Chrome 73

Saya merasakan hal yang sama sampai saya benar-benar menghabiskan belasan jam mencoba mencari tahu
keluar arsitektur Auth0 kami. Percayalah padaku: luangkan waktu sekarang untuk memikirkan ini
keluar dan Anda akan mendapat untung di masa depan.

Pada Rabu, 10 April 2019, 16:06 nchaudry [emailprotected] menulis:

Saya juga pendukung fitur ini. sem*ntara itu bagaimana saya menggunakan
cy.request untuk url dinamis?
Aplikasi kami membuat alur kerja yaitu /workflow/3479 <-- Angka ini dinamis.
Setelah pengiriman formulir, ia menambahkan /task/968 <-- Ini tetap sama selama
jenis alur kerja yang sama dipilih dan dibuat. Url akhir yang kita miliki adalah
sesuatu seperti /workflow/3467/task/968. Kami memiliki server pengujian terbatas
dedikasi, jadi butuh 3 menit untuk mengirimkan formulir, dan itu menyebalkan
dipukul dengan kesalahan CORS. Saya menonaktifkan keamanan web dan aplikasi hanya
lumpuh tanpa pesan untuk konsol. Itu hanya mengatakan
"chrome- error://chromewebdata/ " di runner. Saya pikir ini karena kami
SSO internal, dan saya akan mencoba menerapkan apa yang disebutkan di sso
resep
https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/logging-in__single-sign-on .
Masalahnya bagi saya adalah saya tidak teknis seperti yang saya inginkan, dan itu
akan memakan waktu lama bagi saya untuk mengimplementasikan ini, jika saya bisa. Itu
berkata, bagi saya pribadi atau mungkin orang yang tidak terlalu teknis seperti
baik, akan lebih keren untuk beralih ke domain berikutnya dan melanjutkan dengan
tes saya. Saat ini, saya telah menghabiskan lebih banyak waktu daripada yang saya coba dapatkan
sekitar ini. Saya juga ingin melihat tes e2e yang sebenarnya.

cemara 3.2.0
Windows 10
Chrome 73

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/cypress-io/cypress/issues/944#issuecomment-481865482 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AIeL6o2Hbtgw2xexUAYmKeHiAhiAszLmks5vflJigaJpZM4Ql_rR
.

Inilah solusi peretasan:

Cypress.Commands.add('forceVisit', url => { cy.get('body').then(body$ => { const appWindow = body$[0].ownerDocument.defaultView; const appIframe = appWindow.parent.document.querySelector('iframe'); // We return a promise here because we don't want to // continue from this command until the new page is // loaded. return new Promise(resolve => { appIframe.onload = () => resolve(); appWindow.location = url; }); });});

Bagaimana Anda mendapatkan permintaan xhr muncul. Apa yang ingin saya lakukan adalah sebagai berikut

cy.wait("@aliasVisitWebPage").then( xhr => { const token = xhr.responseBody; cy.log(token); } );

Saya juga memiliki kasus penggunaan yang bagus untuk itu:

Kami ingin memastikan bahwa jika pengguna mengunjungi halaman yang berbeda dan pengguna menghabiskan lebih dari x detik untuk kembali ke situs web kami, jadi ketika pengguna kembali, kami harus logout pengguna tersebut untuk alasan keamanan .

cy.login().then(() => { cy.visit('main-page'); cy.hash().should('eq', '#/main-page');});cy.log('Visit google website');cy.visit('https://www.google.com');cy.wait(15000);cy.go('back');cy.log('User should be logged out');cy.hash().should('not.eq', '#/main-page');

Saya baru mengenal Cypress dan mengevaluasinya untuk kemungkinan penggunaan. Saya juga baru mengenal Javascript. Jadi, saya perlu masuk ke situs yang memiliki pengalihan internal ke URL SSO. Saya memiliki keamanan tetapi masalah tetapi sekarang memiliki
"chromeWebSecurity": salah
saya cypress.json. Saya dapat melewati keamanan tetapi saat dijalankan setelah login melihat halaman kosong. Jadi, tes saya gagal dengan buruk. Tolong, sarankan bagaimana cara mengatasinya?

Terima kasih

jeff

apakah kami memiliki pembaruan tentang solusi untuk itu? Saat ini, masalah ini juga memblokir saya untuk menggunakan cypress untuk beberapa tes yang ingin saya lakukan... karena saya memiliki formulir yang saya kirimkan dan membawa saya ke domain yang berbeda, jadi saya tidak bisa begitu saja menavigasi ke url yang berbeda ini ...

dan menggunakan chromeWe bSecurity:false menyebabkan masalah lain di aplikasi saya, jadi ini bukan pilihan...

Saya juga memiliki masalah dengan banyak domain yang tidak dapat saya atasi (ketergantungan pada pihak ketiga saat ini). Ini diperlukan (dan diinginkan) untuk pengujian ujung ke ujung kami. Saya menghabiskan beberapa waktu agar ini berfungsi dengan memeriksa interaksi browser melalui devtools kemudian mereplikasi dengan panggilan cy.request berturut-turut. Itu tidak cantik tetapi berbagi jika itu membantu orang lain. Cypress adalah alat yang hebat dan saya menghargai komunitas aktif di sekitarnya

cy.get('a') .contains('rabbit hole') .get('a') .invoke('attr', 'href') .then((href) => { cy.request(href) .then ((resp) => { // need to work with the last redirect const postLoginUrl = resp.redirects.pop().split(': ')[1]; // scrape idsrv.xsrf for form post const idsrv = resp.body.match(/idsrv\.xsrf\&quot\;\,\&quot\;value\&quot\;\:\&quot\;(.*?)\&quot\;/)[1]; const postLoginUrlOptions = { method: 'POST', url: postLoginUrl, form: true, body: { "username": username, "password": password, "idsrv.xsrf": idsrv } } cy.request(postLoginUrlOptions) .then ((postResp) => { const postShareUri = postResp.body.match(/consentUrl\&quot\;\:\&quot\;(.*?)\&quot\;\,\&quot\;/)[1]; const scopes = postShareUri.match(/scope\=(.*?)\%20(.*?)\%20/); const postShareUrlHostMatch = postResp.redirects.pop().match(/\d+\: (.*?)\:\/\/(.*?)\//); const postShareUrl = `${postShareUrlHostMatch[1]}://${postShareUrlHostMatch[2]}${postShareUri}`.replace(/\&/g,'&'); const postShareUrlOptions = { method: 'POST', url: postShareUrl, form: true, body: { "idsrv.xsrf": idsrv, "scopes": scopes[1], "scopes": scopes[2], "RememberConsent": "false", "button": "yes" } } // cheesy check that things are on track cy.request(postShareUrlOptions) .then ((postShareResp) => { expect(postShareResp.redirects.length).to.equal(3); }); const logoutUrl = `${postShareUrlHostMatch[1]}://${postShareUrlHostMatch[2]}/logout`; const logoutOptions = { method: 'POST', url: logoutUrl, form: true, body: { "idsrv.xsrf": idsrv, } } cy.request(logoutOptions) .then ((logoutResp) => { expect(logoutResp.body).to.have.string("You are now logged out"); }); }); }) });

Dapatkan token dari penyedia SSO Anda menggunakan cy.request(), Anda tidak boleh
harus meninggalkan domain Anda untuk ini.

Pada Rabu, 19 Jun 2019 pukul 15:16 Francesco Paolo Vitullo <
[emailprotected]> menulis:

Saya sangat menyukai alat ini. sayangnya, ini adalah penghalang besar saat melakukannya
Otentikasi SSO yang mengharuskan pengguna untuk menavigasi ke yang berbeda
domain dan kembali. chromeWebSecurity tidak membantu, jadi tidak yakin bagaimana caranya
selesaikan situasi ini... meskipun, ini tampaknya layak dengan alat lain untuk
Otomatisasi E2E

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
Https://github.com/cypress-io/cypress/issues/944?email_source=notifications&email_token=ACDYX2XNMCKDQBZXETKQK4TP3KHZPA5CNFSM4EEX7LI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBZ2ZDEOR67PWSWZ2ZDEOR67PWZZ2ZDEOR67PWSWZ2ZDEDN5MMVXH
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACDYX2UETL3Z2ONJQATLW6DP3KHZPANCNFSM4EEX7LIQ
.

Berikut adalah kasus penggunaan yang sempurna untuk memerlukan akses ke beberapa "superdomain", yang menggunakan cy.request() tidak akan berfungsi:

Situs web kami, https://shop.nordstrom.com memiliki formulir pencarian di header. Istilah pencarian tertentu menghasilkan pengalihan 302 ke situs web anak perusahaan kami. Mencari

• rack dialihkan ke https://www.nordstromrack.com
• trunk club dialihkan ke https://www.trunkclub.com

Kami menyukai Cypress (sangat!), tetapi tampaknya aneh bahwa tampaknya tidak ada solusi untuk masalah ini.

Selanjutnya... Fakta bahwa tidak ada kesalahan berguna yang diberikan tampaknya aneh. Yang saya dapatkan alih-alih pengalihan yang diharapkan, saya berakhir di chrome- error://chromewebdata/ tanpa penjelasan apa pun.

Saya memiliki masalah yang sama dengan semua orang di atas, tetapi mungkin kerutan yang berbeda.
Kami memiliki aplikasi autentikasi yang digunakan bersama oleh beberapa aplikasi di perusahaan kami, dan itu ada di subdomain berbeda di superdomain yang sama (yaitu, login di https://login.mycompany.com , lalu dialihkan kembali ke aplikasi saya di https://app.mycompany.com ).
Namun, ketika saya menjalankan pengujian terhadap versi aplikasi yang dihosting secara lokal (yaitu login di http://localhost:5555 , aplikasi di http://localhost:7777 ), saya mendapatkan pesan "Anda hanya dapat mengunjungi satu domain unik per test" kesalahan karena port localhost yang berbeda. BTW, ini hanya terjadi ketika saya berlari di Electron (tanpa kepala atau di pelari). Tidak apa-apa ketika saya menjalankan Chrome, karena chromeWebSecurity saya dimatikan.

Saya tahu lebih baik menggunakan permintaan untuk masuk, dan saya melakukannya untuk semua tes saya yang lain -- kasus ini adalah satu tes asap saya yang memastikan integrasi login berfungsi dengan benar.

@jrnail23

kasus ini adalah satu tes asap saya yang memastikan integrasi login berfungsi dengan benar.

Bukankah apa pun yang Anda lakukan melalui cy.request dalam pengujian Anda yang lain sudah mencakup integrasi ini? Jika layanan login Anda tidak berfungsi, maka itu akan gagal dalam tes tersebut.

Di kapal yang sama, kami menggunakan Firebase untuk verifikasi dan kami tidak dapat menavigasi ke tautan Firebase. Tidak bisa hanya menggunakan cy.request() , karena halaman verifikasi perlu dimuat dan beberapa kode pada halaman dijalankan. Semua solusi yang saya temukan, seperti "chromeWebSecurity": false juga tidak berfungsi.

Terkejut masalah ini beredar begitu lama, seperti hal kecil tapi dampak yang besar. Kami ingin pindah dari Dalang, tapi kami tidak bisa saat ini menghalangi kami. Bahkan tidak bisa menulis tes pendaftaran sederhana.

Saya setuju dengan orang banyak di sini. Solusi yang disediakan bukanlah solusi nyata. Tes ujung ke ujung seharusnya tidak memiliki jenis peretasan apa pun di antaranya. Saya ingin tes saya berperilaku persis seperti manusia.

Manusia tidak akan menghentikan permintaan, menyalin token, dan mengubah API saya untuk memaksa masuk menggunakan autentikasi pihak ketiga.

+1000

Dengan sekarang banyak aplikasi yang berjalan dengan auth0 dan banyak lainnya, ini sebenarnya menjadi pemblokir yang sangat besar. Memang saya mengerti mengapa itu tidak berhasil dan bagaimana cara kerja cypress bagian dalam tidak memungkinkan ini, namun masih ada dan menjadi penghambat.

Mungkin plugin chrome? Atau peretasan di kromium?

Untuk menambah paduan suara, kami telah menginvestasikan waktu dan sumber daya di Cypress sebelum menemukan pemblokir ini. Pengujian di seluruh domain super bukanlah hal yang aneh dalam pengujian aplikasi modern - sebuah konsep yang diklaim Cypress sebagai keunggulannya.

Sangat menantikan pembaruan tentang masalah ini, bagi kami akan sangat disayangkan jika harus mengalihkan semuanya kembali ke Webdriver.

Halo semuanya,
Saya baru mengenal Cypress, sangat bersemangat untuk mencoba ini setelah mendengar banyak desas-desus dari teman-teman. Juga menghabiskan banyak waktu untuk mencari tahu mengapa pengujian saya tidak dapat terhubung ke situs federasi dari Host lain untuk tujuan otentikasi. Sekarang, saya mengerti ini dikenal diblokir dari beberapa tahun.

Adakah yang bisa menjelaskan kepada saya apakah peretas di bawah ini yang diposting oleh pengguna lain berfungsi?

Cypress.Commands.add('forceVisit', url => { cy.get('body').then(body$ => { const appWindow = body$[0].ownerDocument.defaultView; const appIframe = appWindow.parent.document.querySelector('iframe'); // We return a promise here because we don't want to // continue from this command until the new page is // loaded. return new Promise(resolve => { appIframe.onload = () => resolve(); appWindow.location = url; }); });});

Akhirnya, saya dapat membantu Anda semua yang ingin mengunjungi domain lain di dalam tes Cypress.

_Percobaan pertama saya adalah menjalankan tes Cypress dari dalam tes Cypress lain:_

cy.exec("npx cypress run --spec path/to/test.js --headed") .then((result) => { console.log(result) })

_Meskipun berhasil (menjalankan instance Cypress kedua yang menjalankan tes kedua), itu sangat lambat dan tidak menyimpan data sesi (cookie, dll.)._

PERCOBAAN KEDUA SAYA MENGIZINKAN SAYA MENGUNJUNGI DOMAIN TIDAK TERBATAS!:

Pertama, Anda perlu menambahkan Dalang ke proyek Anda:

npm install puppeteer

Kemudian Anda dapat menggunakannya seperti ini:

Tes orang tua:

blahblahblahcy.exec("node path\\to\\file.js --headed", {timeout: 180000}) .then((result) => { console.log(result.stdout) })blahblahblah

Tes anak:

const puppeteer = require('puppeteer');puppeteer.launch({headless: false, userDataDir: "./user_data"}).then(async browser => { const page = await browser.newPage(); await page.goto('https://www.google.com'); await page.waitFor('some_element'); const message = await page.evaluate(() => document.querySelector('some_element').innerText) console.log(message) await browser.close(); });

Catatan penting:

• Jika Anda menjalankan kode di Windows, JANGAN gunakan apa pun selain CMD.exe untuk menjalankan Cypress, jika tidak, Anda akan mendapatkan kesalahan:

https://github.com/cypress-io/cypress/issues/789

• console.log(message) digunakan dalam uji anak untuk mengirim data ke STDOUT. Itu kemudian ditangkap oleh result.stdout dalam pengujian induk. Anda juga dapat menggunakan STDERR untuk menampilkan data ( console.error sebagai ganti cypress.log dalam uji anak dan result.stderr dalam uji induk)

• Harap diingat bahwa ketika Anda menjalankan cy.exec(), CWD (Current Working Directory) Anda adalah root dari repositori Cypress Anda, jadi untuk menjalankan tes apa pun Anda perlu menggunakan jalur relatif, seperti cypress\\integration\\mytest.js

• Anda dapat mempersingkat kode untuk mendapatkan teks dari elemen:

https://github.com/GoogleChrome/puppeteer/issues/3260#issuecomment -422081505

Dari pada

await page.evaluate(() => document.querySelector('#my-sweet-id').innerText)await page.evaluate(() => document.querySelector('#my-sweet-id').innerHTML)

Anda dapat menggunakan page.$eval:

await page.$eval('#my-sweet-id', e => e.innerText);await page.$eval('#my-sweet-id', e => e.innerHTML);

NIKMATI!

Jika Anda memiliki pertanyaan, tanyakan saja :) Ini berfungsi dengan baik untuk saya dan mengatasi masalah dengan mengunjungi lebih dari satu superdomain dalam satu pengujian.

@jrnail23 Terima kasih! Saya sepenuhnya mengalami betapa frustasinya ketika Anda memiliki kerangka kerja Anda hampir siap dan kemudian BAM! - Anda menemukan masalah seperti ini. Saya _dapat_ membayangkan motivasi di balik menjaga pengujian dalam batas-batas satu superdomain tetapi ada beberapa situasi ketika Anda tidak ingin/membutuhkan/memiliki waktu atau pengetahuan untuk membangun sistem pengujian kedua hanya untuk meniru tindakan server menggunakan permintaan. Dalam kasus saya, saya perlu mengunjungi halaman terpisah yang memuat banyak skrip sisi klien, inilah mengapa saya mulai dengan menjalankan tes Cypress bersarang dan diakhiri dengan pembungkus untuk Dalang. Saya tidak dapat menggunakan permintaan sederhana tanpa mensimulasikan banyak pekerjaan yang dilakukan oleh skrip yang dapat dijalankan oleh browser yang berfungsi dengan baik.

@ankeshdave Saya melihat sekilas mekanisme SSO dan jawaban saya adalah: menggunakan metode saya, Anda dapat mengembalikan apa pun yang Anda inginkan dari tes anak. Mekanisme SSO memberi Anda token yang perlu digunakan saat membuat permintaan berikutnya. Anda harus dapat mengekstrak token (atau lebih baik, mengembalikan nilai melalui STDOUT dari tes anak ke result.stdout dari tes induk) dan kemudian memasukkan token ke tempat yang tepat. Mungkin menarik untuk bekerja sama dengan SSO menggunakan metode saya. Saya sepenuhnya menyadari bahwa tidak setiap SSO berada di bawah kendali Anda, jadi jika Anda berhasil menerapkan solusi saya dalam kode Anda, silakan bagikan dengan kami dan saya dapat mencoba menyiapkan solusi yang lebih umum untuk penggunaan SSO di Cypress.

@you1anna , perlu diketahui bahwa masalah ini ditandai dengan tag "papan produksi" beberapa hari yang lalu, jadi saya harap pembuat Cypress menangani masalah ini dengan serius dan akan berupaya untuk mempermudah kami membuat pengujian di Cypress.

Saya memerlukan fitur ini untuk menavigasi di antara dua aplikasi yang kami miliki. Kami perlu menguji bahwa aplikasi administratif kami berubah ke pengaturan memperbarui aplikasi yang menghadap publik kami. Aplikasi ini berjalan pada port yang berbeda secara lokal. Sepertinya kita harus kembali ke codecept, karena ini tidak akan berhasil untuk kita. Ini menyedihkan karena saya sangat bersemangat menggunakan cemara. Rasanya pembatasan ini dipaksakan secara tidak perlu.

Saya menghadapi masalah serupa, tidak dapat menavigasi antara aplikasi yang berjalan di port yang berbeda

Bukannya saya secara aktif menyumbangkan solusi dengan PR atau peretasan/solusi, tetapi:

Saya akan menambahkan "+1" saya.

Dianggap menggunakan ini untuk klien yang sedang berkembang dan sayangnya ini bukan pemula karena kami adalah SSO yang perlu diuji terhadap/di 100-an situs (situs klien -> SSO kami -> situs klien, dll, dll).

Sayang sekali, Cypress sangat menonjol dan menjanjikan.

@pkuczynski terima kasih tapi saya sudah mencobanya.

Cypress.Commands.add("login", () => { cy.getCookie("automation").then(cookie => { if (!cookie) { cy.exec("node ../costar-suite/cypress/helpers/login.js --headed", { timeout: 180000 }).then(res => { const cookies = JSON.parse(res.stdout); cy.log(cookies); for (let cookie of cookies) { cy.setCookie(cookie.name, cookie.value, omit(["name", "value", cookie])); } }); } });});before(function() { cy.login();});

Login.js

const puppeteer = require("puppeteer");puppeteer .launch({ args: ["--ignore-certificate-errors", "--enable-features=NetworkService"], }) .then(async browser => { const page = await browser.newPage(); await page.goto("http://localhost.com:4000/"); await page.waitForSelector(".login-form-component"); await page.type("#username", "username"); await page.type("#password", "pass"); await page.waitForSelector("#loginButton"); await page.click("#loginButton"); await page.waitForSelector(".navigation-container li a"); const cookies = await page.cookies(); console.log(JSON.stringify(cookies)); await browser.close(); });

Saya telah berjuang dengan ini untuk sem*ntara waktu, jadi inilah implementasi saya saat ini dengan banyak terima kasih atas tip menggunakan dalang dan cy.task() . Aplikasi kami menggunakan OAuth2 untuk semua autentikasi, juga aplikasi pihak pertama. Jadi saya harus menavigasi ke halaman di port yang berbeda (login-server) untuk login pengguna. Itu sekarang ditangani oleh tugas cemara melalui dalang. Dalang masuk, lalu mendapatkan seluruh model pengguna (hanya token yang juga bisa berfungsi dalam kasus Anda) dan mengembalikannya ke tugas. Tugas kembali mengembalikan itu. Saya membuat perintah khusus cypress untuk memulai tugas, mendapatkan model pengguna, mengaturnya di penyimpanan lokal, dan kemudian pengujian saya dapat berjalan.

plugins/index.ts

module.exports = (on, config) => { on('task', { login({ username, password }) { return (async () => { const browser = await puppeteer.launch({ ignoreHTTPSErrors: true }); const page = await browser.newPage(); await page.goto('https://my-app.test:4200', { // The app redirects to the login-page waitUntil: 'networkidle2' // Wait until login-page has been reached }); await page.type('#email', username); // Insert username in form await page.type('#password', password); // Insert password await page.click('button[type="submit"]'); // Click login button await page.waitForNavigation({ waitUntil: 'networkidle2' }); // Wait until redirected back to the app const user = await page.evaluate(() => { // Get the user-model from localStorage return localStorage.getItem('user'); }); await browser.close(); // Close puppeteer return user; // Return the user-model to Cypress })(); } });

Kemudian di support/index.ts (atau file lain yang diimpor support/index.ts )

Cypress.Commands.add('login', (username, password) => { cy.task('login', {username: username, password: password}).then(user => { window.localStorage.setItem('user', user); });});

Dan akhirnya dalam pengujian saya whatever-test.spec.ts

describe('Whatever test', () => { it('should login and do some stuff', () => { cy.login('[emailprotected]', 'SomeSecretPassword'); });});

Semoga ini akan membantu seseorang yang menghadapi masalah yang sama. Jika Anda tidak dapat membuatnya bekerja, jangan ragu untuk mengirimi saya pesan, saya dapat membantu Anda jika saya dapat menemukan waktu ;-).

Ya, itu bisa dilakukan. Pertanyaan cepat - apakah ada alasan Anda memerlukan _browser_ untuk memuat 500 domain berbeda dan mengklik tombol?

Bukankah akan jauh lebih mudah untuk menggunakan cy.request atau cara program lain untuk mencapai ini?

Misalnya, apa yang dilakukan mengklik tombol? Mengirim permintaan HTTP adalah tebakan saya. Jadi alih-alih menggunakan UI, cukup kirim permintaan HTTP secara langsung menggunakan cy.request . Hasil yang sama, 100x lebih cepat, dan tidak ada masalah domain.

Setiap informasi tambahan tentang kasus penggunaan Anda akan sangat membantu.

Saya sudah sangat menyadari praktik terbaik yang mengatakan bahwa kita harus masuk secara terprogram melalui permintaan API dan bukan melalui UI. Ini bekerja dengan baik di aplikasi sederhana seperti wastafel dapur, todos, apel dan jeruk, dll. Tetapi aplikasi tingkat perusahaan sedikit lebih kompleks daripada mendapatkan token hanya dengan melakukan satu cy.request() ke /apples/oranges/giveMeUserToken titik akhir. Hanya untuk memberikan gambaran umum tentang kerumitannya, tim pengembang kami didistribusikan di beberapa negara/zona waktu dan ada sekitar 7 panggilan autentikasi multifaktor yang berbeda di mana token dilewatkan di antara header dan parameter API ini untuk mengambil cookie sesi terakhir. Setiap panggilan berikutnya tergantung pada keaslian token dari panggilan sebelumnya. Belum lagi token ini diubah secara berkala untuk tujuan keamanan. Semua ini dimiliki oleh tim keamanan yang berada di lokasi bersama yang berbeda yang berada di luar jangkauan tim fitur. Untuk mendapatkan token, Anda harus melakukan ping ke 7 tim berbeda di tengah malam untuk mendapatkan rahasia yang hanya akan berlaku selama seminggu atau lebih. Oleh karena itu, masuk melalui API tidak perlu dipertanyakan lagi di sini.

Menginginkan panduan lengkap tentang proses pendaftaran dan login kami (menggunakan firebase auth), saya menggunakan metode berikut untuk membuka paksa domain/url lain di browser cypress. Terinspirasi oleh cuplikan dari @suchipi :

Cypress.Commands.add('forceWindow', url => { cy.get('body').then(body$ => { let newWindow = open(url) return new Promise(resolve => { setTimeout(x => { newWindow.close() resolve() }, 2000) }) });});

Ini berfungsi dengan domain apa pun tetapi saya tidak menguji menggunakan cy di domain/jendela lain, karena kami hanya perlu membuka jendela ini sehingga browser cypress masuk (cy.request() tidak berfungsi):

cy.forceWindow(loginLink).then(x => { cy.reload()})

Perbaikan selamat datang.

Aplikasi kami menggunakan server Identitas untuk otentikasi sehingga kami harus dapat mengarahkan ulang dari superdomain untuk menangani otentikasi dan kembali ke domain tempat kami memulai. Kami telah memisahkan pengujian dalam satu pengujian yang melakukan tindakan login dan pengujian lainnya yang melakukan navigasi dan validasi. Sebelum pemisahan ini berfungsi karena cookie sesi tetap ada dan dapat digunakan untuk kasus uji validasi tetapi sepertinya ini telah diubah akhir-akhir ini. Saran dipersilahkan

Satu lagi pembaruan untuk yang ini: apa yang saya lakukan adalah mempertahankan cookie sesi dengan daftar putih cookie pada uji navigasi dan validasi. Solusi ini berfungsi, tetap saja akan menyenangkan untuk dapat menavigasi antara IDS dan aplikasi lainnya.

Perusahaan saya sedang membangun layanan Oauth dan kami memiliki beberapa domain. Kami harus dapat mengarahkan ulang dari satu ke yang lain dan belum memiliki kemampuan untuk masuk secara terprogram. Faktanya, kami ingin menguji proses login OAuth kami seperti pengguna nyata dan kami tidak bisa karena Cypress tidak mengizinkan kami mengunjungi domain yang berbeda.

Ini sangat menyakitkan dan kami menolak untuk "meretas" ini dengan iframe / dalang atau solusi lain, itu terlalu kotor dan kami tidak dapat memasukkannya ke basis kode kami (bahkan jika ini adalah solusi keren ).

Apa yang saya tidak mengerti adalah: Anda melihat pengguna bahwa Anda memiliki praktik yang baik, dan itu hal yang baik, tetapi di sini, Cypress hanya mengatakan "TIDAK!" untuk apa yang ingin kita lakukan dan, karena itu, sama sekali tidak berguna untuk beberapa kasus yang ingin kita uji.

Saya bahkan mencoba menggunakan {chromeWebSecurity: false} tetapi, meskipun ini berhasil sekali dengan versi Chrome lama, sekarang tidak lagi.

apakah ada solusi yang tersedia, dengan cemara, untuk melakukan apa yang saya inginkan?

EDIT: Setelah pembicaraan panjang dengan tim, kami setuju untuk mengubah proses kami karena kami memikirkan cara Cypress dalam melakukan sesuatu dan memutuskan untuk menyingkirkan tes strategi OAuth jaringan sosial kami.
Kami akan menguji ini secara berbeda. Kami "meretas" masalah memiliki banyak aplikasi di domain yang berbeda di pihak kami dengan mendaftarkan semuanya di domain yang sama di lingkungan ulasan (formulir masuk, layanan email / sms, dan aplikasi pihak ketiga yang ingin menggunakan solusi kami)

Setelah 2 bulan berjuang dengan fitur/masalah yang tidak berarti ini (pemblokir baca), kami akhirnya memutuskan untuk membuang Cypress keluar dari jendela dan mengadopsi Dalang sebagai otomatisasi pengujian E2E kami.
Tes menulis dengan Dalang bukanlah pengalaman yang baik dibandingkan dengan Cypress. Tetapi eksekusi tes secara mengejutkan lebih cepat secara eksponensial + Anda mendapat kemewahan untuk menguji di banyak browser + berjalan lebih cepat di saluran CI karena gambar buruh pelabuhan yang jauh lebih kecil ....dan coba tebak !!! Anda benar-benar dapat merutekan aplikasi Anda melalui 100 domain berbeda untuk mendapatkan cookie sesi yang Anda butuhkan...tanpa seseorang memberi tahu Anda bahwa itu bukan "praktik terbaik" dan mengunci Anda ke dalam satu domain

kami mencapai keputusan yang sama dan menggabungkan Dalang dengan Jest.

@jennifer-shehane Saya ingin bertanya... Bagaimana sikap tim cypress tentang masalah ini?
Apakah ada kemungkinan untuk membuatnya fleksibel, atau sebagai pilihan desain akan terus seperti itu?

Tampaknya seperti blok yang benar untuk banyak orang. Sangat frustasi harus meninggalkan cypress ketika Anda menyadari bahwa Anda tidak memiliki opsi atau solusi sederhana untuk skenario seperti itu. Dan skenario ini bahkan tidak jarang! Jika Anda menggunakan otentikasi OIDC pada server identitas, Anda sudah selesai untuk... Cypress tidak layak dalam skenario ini kecuali Anda siap untuk melakukan beberapa solusi gila

Saya lelah menunggu karena ketika melihat kodenya Anda akan mengerti bahwa itu tidak akan pernah berubah.

Jika Anda menginginkan solusi lain, saya merekomendasikan CodeceptJS.

Salah thread Pak Mikael. Ini adalah komunitas non-selenium. CodeceptJs hanyalah pembungkus Selenium.

Tidak juga, ini juga untuk Dalang dan berfungsi baik dengan Browserless.

"chromeWebSecurity": false, tidak berfungsi pada versi chrome terbaru.

Saya beralih di antara subdomain yang berbeda (HTTPS dan HTTP) tetapi dengan domain yang sama, dan saya masih mendapatkan ini:

ypressError: cy.visit() failed because you are attempting to visit a second unique domain.You may only visit a single unique domain per test.Different subdomains are okay, but unique domains are not.The previous domain you visited was: 'https://yyy.domain.io'You're attempting to visit this new domain: 'http://xxx.domain.io'You may need to restructure some of your code to prevent this from happening.https://on.cypress.io/cannot-visit-second-unique-domain

"chromeWebSecurity": false, tidak berfungsi pada versi chrome terbaru.

Saya memiliki masalah yang sama. Itu bekerja dengan baik beberapa hari yang lalu. Ada solusi untuk ini? Terima kasih!

Saya mengelolanya dengan menggunakan domain yang sama dan protokol yang sama (https untuk keduanya).

Oh, saya tidak bisa melakukan hal yang sama karena kami menggunakan SSO yang dihosting di domain lain

Sayang sekali tidak ada yang akan berbicara tentang masalah ini karena mengganggu begitu banyak orang yang menggunakan produk atau ingin menggunakan produk. Saya memiliki seluruh rangkaian pengujian yang menggunakan Cypress untuk salah satu produk perangkat lunak kami, tetapi untuk produk kami yang lain, kami tidak dapat menggunakannya karena beberapa pengalihan superdomain saat masuk. Saya telah mencoba banyak hal berbeda untuk membuat Cypress bekerja dengannya tetapi tidak berhasil. Harus terus menggunakan Busur Derajat, tetapi saya lebih suka menggunakan Cypress.

Saya pikir semua orang akan menghargai komentar dengan satu atau lain cara dari tim Cypress, apakah masalah ini bahkan ada di radar Anda.

Tim Cypress masih bermaksud untuk mengatasi masalah ini karena masih dalam lingkup pekerjaan dan peta jalan untuk produk kami. Pekerjaan yang diperlukan untuk memperbaikinya sangat besar dan saling terkait dengan masalah lain yang melibatkan fungsionalitas inti Cypress.

Masalah ini masih dalam tahap 'proposal', yang berarti belum ada pekerjaan yang dilakukan untuk masalah ini sampai hari ini, jadi kami tidak memiliki perkiraan kapan akan dikirimkan.

Heh, hari pertama saya dengan Cypress dan ini terjadi ... :/

Hahaha, kamu beruntung. Bayangkan orang-orang menghabiskan 3-6 bulan untuk membangun seluruh rangkaian tes dari 100+ tes dan kemudian menyadari di tengah jalan bahwa mereka tidak dapat melanjutkan lebih jauh karena bug ini :)

@abhidp Ya, ini tidak dapat diterima.
Seharusnya tidak mengejutkan tim Cypress kan? Mungkin versi Chrome-beta menunjukkan bahwa masalah ini pada akhirnya akan datang.
@jennifer-shehane apakah Anda mengikuti perubahan chrome-beta untuk mencegah perubahan seperti ini?

Saya berhasil membuatnya berfungsi dengan memuat ekstensi yang mengizinkan paksa situs lintas-Asal:
Saya menggunakan ekstensi ini: https://github.com/vitvad/Access-Control-Allow-Origin

1. Anda dapat mengunduhnya menggunakan: https://github.com/vitvad/Access-Control-Allow-Origin/archive/master.zip
2. Buka zip ekstensi ke fe cypress/ekstensi
3. Buat Cypress memuat ekstensi sebelum pengujian - cypress/plugins/index.js akan terlihat seperti:

module.exports = (on, config) => { on("before:browser:launch", (browser, launchOptions) => { if (browser.name === "chrome") { launchOptions.args.push( "--load-extension=cypress/extensions/Access-Control-Allow-Origin-master" ); return launchOptions; } });};

Sekarang pengujian multidomain Anda harus berjalan dengan baik. Ekstensi tidak memerlukan konfigurasi manual.

Inilah solusi peretasan:

Cypress.Commands.add('forceVisit', url => { cy.get('body').then(body$ => { const appWindow = body$[0].ownerDocument.defaultView; const appIframe = appWindow.parent.document.querySelector('iframe'); // We return a promise here because we don't want to // continue from this command until the new page is // loaded. return new Promise(resolve => { appIframe.onload = () => resolve(); appWindow.location = url; }); });});

Tidak berfungsi untuk saya, setelah meneruskan url ke cy.forceVisit(), tidak ada yang terjadi ;/

1. Anda mengonfigurasi ekstensi

Saya tidak begitu mengerti langkah 4, dapatkah Anda menjelaskan?

@kamil-rogowski-gc Saya telah memperbarui posting dengan panduan

@kamil-rogowski-gc Saya telah memperbarui posting dengan panduan

Ok terima kasih tapi saya tidak bisa melihat ekstensi ini. Akan bekerja solusi ini pada CI? Seperti yang saya lihat Anda melakukan sesuatu di browser secara manual

Maaf teman-teman, tapi saya mungkin salah memberi tahu Anda.
Saya baru saja menginstal ulang semuanya, melakukan tes bersih tanpa ekstensi, tidak ada perubahan khusus dan agak acak. Saya kira itu tergantung pada proxy Cypress dan "waktu" - ketika sesuatu terjadi dan dalam urutan apa.
Terlepas dari metode yang digunakan untuk memulai tes, terkadang semuanya berjalan dengan baik, terkadang yang pertama berhasil dan sisanya gagal karena omong kosong lintas asal, dan terkadang semua tes gagal...

Secara keseluruhan, ini adalah masalah serius di pihak Cypress dan sepertinya tidak ada solusi yang berhasil - seperti 2 tahun yang lalu.

Maaf teman-teman, tapi saya mungkin salah memberi tahu Anda.
Saya baru saja menginstal ulang semuanya, melakukan tes bersih tanpa ekstensi, tidak ada perubahan khusus dan agak acak. Saya kira itu tergantung pada proxy Cypress dan "waktu" - ketika sesuatu terjadi dan dalam urutan apa.
Terlepas dari metode yang digunakan untuk memulai tes, terkadang semuanya berjalan dengan baik, terkadang yang pertama berhasil dan sisanya gagal karena omong kosong lintas asal, dan terkadang semua tes gagal...

Secara keseluruhan, ini adalah masalah serius di pihak Cypress dan sepertinya tidak ada solusi yang berhasil - seperti 2 tahun yang lalu.

Ya, saya terkejut bahwa seseorang menemukan solusi untuk masalah lama ini pada hari pertama mereka dengan Cypress. Saya sangat bersemangat untuk mencoba solusi Anda, tapi .... kekecewaan, seperti 2 tahun yang lalu :(

Dalam kasus saya, saya harus menunggu permintaan dari sekumpulan API aplikasi saya

Jadi, aplikasi saya berjalan sebagai http://localhost:8089 , dan menunggu permintaan seperti https://dev-service.domain.com . Permintaan XHR juga tidak muncul di panel sebelah kiri

Tetapi, ketika saya menjalankan tes terhadap server dev https://dev-app.domain.com , waktu tunggu berfungsi dan saya dapat melihat permintaan XHR di panel sebelah kiri. Apakah ini juga efek sampingnya?

Dalam aplikasi kami, klik tombol mengarah ke domain lain, di mana url redirect dalam kasus kami dihasilkan secara dinamis dan setiap kali unik karena implementasi Okta. Cypress memberi saya kesalahan yang dijelaskan dalam komentar lain yang disebutkan di atas tentang kesalahan lintas asal. Dengan tips dan trik dalam dokumentasi Cypress (https://docs.cypress.io/guides/guides/web-security.html#Same-superdomain-per-test) saya menemukan solusi peretasan untuk kasus pengujian kami.

Dengan membagi bagian mendapatkan url redirect di sebelumnya dan melanjutkan sisa kasus pengujian saya dalam pengujian itu sendiri, saya dapat menggunakan url redirect dalam kunjungan saya di sana. Dengan cara ini saya masih memiliki kasus uji yang dekat dengan pengalaman pengguna dan yang ada di beberapa domain.

describe('Login', () => { let testUrl: string | null; before((tileIndex: number) => { cy.clearCookies(); cy.visit('/'); cy.login(); cy.get('data-test') .eq(tileIndex) .click() .then(xhr => { testUrl = (Cypress.$(xhr))[0].children[0].getAttribute('href'); }); }); it('Single sign-on is succesfull', () => { cy.visit(`${testUrl}`); cy.get('data-test').click(); });}); 

Semoga membantu seseorang!

cy.login('[emailprotected]', 'SomeSecretPassword');

Acara 'tugas' belum terdaftar di file plugin. Anda harus mendaftarkannya sebelum menggunakan cy.task()

@jennifer-shehane Saya melihat banyak komentar tentang orang yang membutuhkan ini. Ingin menggemakan penggunaan dunia nyata dan membutuhkan ini untuk manajemen sesi koneksi openid .

Karena kebijakan untuk mencegah dua asal dalam pengujian, kami tidak dapat menguji otentikasi kami sebagai pengujian integrasi menggunakan cypress.

Kami memiliki aplikasi satu halaman yang merupakan pihak yang sepenuhnya bergantung pada penyedia Oauth yang ada di dalam sistem kami. Itu di-host di subdomain terpisah. Untuk login awalnya kita redirect ke situs auth. sem*ntara pada klien ketika pengguna harus menegur bahwa mereka adalah mereka, kami menampilkan modal yang merupakan iframe sehingga cookie yang tepat ditetapkan dari penyedia Oauth pada login tersebut.

Saya benar-benar berharap ini keluar dari kotak juga.
Saya harus mengautentikasi dengan auth0 dan melalui aplikasi kami yang akan memicu masalah dalam masalah ini. Saya membaca artikel auth0 e2e cypress tentang cara mengatur auth. dengan cy.request() tetapi mereka menggunakan grant_type: password yang merupakan sesuatu yang tidak ingin saya sertakan dalam aplikasi saya.

Saya ingin menguji halaman login juga, jadi, untuk melewati batasan ini, saya menggunakan Puppeteer do login dan membuat cookie:

const browser = await puppeteer.launch({ args: ['--no-sandbox', '--disable-setuid-sandbox'] }); // Needed to run inside dockerconst page = await browser.newPage();await page.goto(URL);await page.type('#username', USERNAME);await page.type('#password', PASSWORD);await page.click('.ulp-button');const auth0Cookies = await page.cookies();browser.close();

dan kemudian menjalankan cypress dengan:

await cypress.run({ config: { video: false, env: { auth0Cookies } }})

dan dalam file spesifikasi:

Cypress.env('auth0Cookies').forEach(({ name, value, domain, expires, httpOnly, path, secure }) => { cy.setCookie(name, value, { domain, expiry: expires, httpOnly, path, secure, }); });cy.visit(URL)

Dan oleh karena itu, karena cookie sudah disetel, halaman login auth0 tidak muncul dan saya bisa langsung masuk ke halaman aplikasi dan tidak ada dua domain super, tetapi masih berhasil menguji login dan halaman aplikasi

Semoga ini bisa membantu seseorang :)

Ini sangat relevan mengingat "chromeWebSecurity": false tidak berfungsi.

Bahkan jika itu berhasil, itu akan memberi Anda gambaran berapa banyak orang yang benar-benar menyetelnya ke false... yang merupakan jawaban utama untuk masalah ini.

--edit tautan yang dihapus ke masalah yang berbeda

Skenario dunia nyata yang membutuhkan dukungan ini:

A1 = aplikasi web 1
A2 = aplikasi web 2 (domain berbeda)

1) Masuk ke A1 untuk mengajukan klaim
2) Ajukan klaim di A1
3) Beralih ke A2 untuk menyetujui klaim
4) Setujui klaim di A2
5) Beralih ke A1 untuk melihat klaim yang disetujui
6) Validasi detail klaim yang disetujui di A1

Saya benar-benar berharap ini keluar dari kotak juga.
Saya harus mengautentikasi dengan auth0 dan melalui aplikasi kami yang akan memicu masalah dalam masalah ini. Saya membaca artikel auth0 e2e cypress tentang cara mengatur auth. dengan cy.request() tetapi mereka menggunakan grant_type: password yang merupakan sesuatu yang tidak ingin saya sertakan dalam aplikasi saya.

Saya ingin menguji halaman login juga, jadi, untuk melewati batasan ini, saya menggunakan Puppeteer do login dan membuat cookie:

const browser = await puppeteer.launch({ args: ['--no-sandbox', '--disable-setuid-sandbox'] }); // Needed to run inside dockerconst page = await browser.newPage();await page.goto(URL);await page.type('#username', USERNAME);await page.type('#password', PASSWORD);await page.click('.ulp-button');const auth0Cookies = await page.cookies();browser.close();

dan kemudian menjalankan cypress dengan:

await cypress.run({ config: { video: false, env: { auth0Cookies } }})

dan dalam file spesifikasi:

Cypress.env('auth0Cookies').forEach(({ name, value, domain, expires, httpOnly, path, secure }) => { cy.setCookie(name, value, { domain, expiry: expires, httpOnly, path, secure, }); });cy.visit(URL)

Dan oleh karena itu, karena cookie sudah disetel, halaman login auth0 tidak muncul dan saya bisa langsung masuk ke halaman aplikasi dan tidak ada dua domain super, tetapi masih berhasil menguji login dan halaman aplikasi

Semoga ini bisa membantu seseorang :)

Pastinya begitu ❤️ Terima kasih banyak.

Menginginkan panduan lengkap tentang proses pendaftaran dan login kami (menggunakan firebase auth), saya menggunakan metode berikut untuk membuka paksa domain/url lain di browser cypress. Terinspirasi oleh cuplikan dari @suchipi :

Cypress.Commands.add('forceWindow', url => { cy.get('body').then(body$ => { let newWindow = open(url) return new Promise(resolve => { setTimeout(x => { newWindow.close() resolve() }, 2000) }) });});

Ini berfungsi dengan domain apa pun tetapi saya tidak menguji menggunakan cy di domain/jendela lain, karena kami hanya perlu membuka jendela ini sehingga browser cypress masuk (cy.request() tidak berfungsi):

cy.forceWindow(loginLink).then(x => { cy.reload()})

Perbaikan selamat datang.

Ini berhasil untuk saya. Saya mencoba mengklik tombol di dalam email di Mailosaur untuk memverifikasi pembuatan akun di situs kami. (Saya membuat akun di UI kami. Dan verifikasi email harus dilakukan di akun Mailosaur. Saya menemukan email terkirim dan harus mengklik tombol verifikasi email untuk memverifikasi) Saya sudah memiliki url dari cy.request. Tetapi saya tidak tahu cara mengklik tombol karena fakta bahwa itu pergi ke domain yang berbeda. Saya menggunakan potongan kode ini dan itu berfungsi dengan baik. Ini adalah bantuan besar.
Terima kasih @wingsuitist
Saya akan sangat menghargai jika Anda dapat menjelaskan ini sedikit dari baris ke-2,

cy.get('body').then(body$ => {

 let newWindow = open(url) return new Promise(resolve => { setTimeout(x => { newWindow.close() resolve() }, 2000) })

Saya tidak begitu mengerti mengapa tidak ada solusi mudah bagi orang yang benar-benar membutuhkan fitur ini. Saya suka kerangka kerja berpendirian, tetapi ada alasan yang sah untuk mengunjungi (untuk kami setidaknya 2) port dalam satu pengujian dan tidak, cy.request tidak selalu merupakan cara yang tepat untuk menyelesaikan ini dan menonaktifkan chromeWebSecurity tidak membantu di sini. Masalah ini telah terbuka selama 2 1/2 tahun, memiliki 126 komentar dan saya hanya ingin tahu mengapa masih terbuka, karena rasanya pengelola tidak bersedia setidaknya menawarkan solusi yang agak layak.

Terima kasih kepada @suchipi karena telah memberikan solusi yang untungnya berhasil bagi kami <3

hal. Terima kasih kepada semua orang yang mengerjakan alat hebat ini <3 Berasal dari tahun Capybara (yang sebenarnya bukan alat yang buruk), saya sangat menyukai Cypress untuk semua yang ditawarkannya!

Sangat mengejutkan melihat itu tidak dianggap sebagai bug. Di halaman beranda itu menyatakan pengujian End-2-End.
Persepsi saya tentang pengujian End-2-End mencakup aliran bisnis yang lengkap. Tidak hanya menguji front-end dari satu aplikasi.

Saya sangat berharap saya akan dimungkinkan untuk melakukan langkah-langkah berikut dalam satu tes:
cy.visit('https://company-application-a.nl')...
verifikasi fungsi buat di aplikasi front-end
cy.visit('https://company-application-b.nl')...
verifikasi fungsi baca di aplikasi back-office

Jika seseorang memiliki solusi untuk saat ini, itu akan bagus. Saya mencoba semua solusi lain di atas tetapi sepertinya tidak mendapatkan hasil yang diinginkan.

Saya pikir Cypress memiliki potensi besar! Jadi teruslah bekerja dengan baik.

Kami juga bergantung pada beberapa sistem di domain yang berbeda untuk diuji secara keseluruhan, yang saat ini tidak mungkin karena pembatasan buatan ini.

Saya tidak menentang pendapat dan mencoba membuat kasus untuk memisahkan sistem yang berbeda dalam tes yang berbeda, tetapi dunia nyata tidak sempurna.

Jika ada cara untuk setidaknya menonaktifkan pembatasan ini bagi kita yang memiliki sistem yang tidak dapat diubah dalam semalam (atau bahkan di tahun depan), maka itu akan membantu kita semua.

Cypress dapat mempertahankan pendapat mereka tentang bagaimana dan apa yang harus diuji, di luar kebiasaan, dan menganjurkan pemikiran mereka tentang hal itu. Dan bagi orang-orang yang mungkin setuju, tetapi tidak memiliki kemewahan untuk mengikuti petunjuk itu: kita bisa mengatasinya.

Terima kasih telah mempertimbangkannya, ini akan menjadi perubahan yang disambut baik dan mungkin akan membantu saya untuk terus menggunakan Cypress daripada harus beralih ke alat lain.

Tim kami saat ini sedang berupaya membuat pengalaman yang lebih baik seputar pengujian autentikasi, yang merupakan kasus penggunaan besar yang tercakup dalam masalah ini. Kami tahu bahwa banyak orang tidak puas dengan pendekatan pengujian otentikasi saat ini secara terprogram dan kami ingin mengatasi masalah tersebut.

Ada beberapa fase untuk mengatasi inti masalah dengan autentikasi pengujian yang akan kami luncurkan sepotong demi sepotong. Kami membaca komentar semua orang dan menggunakannya untuk mengevaluasi cara mendekati pekerjaan di depan kami.

Saya setuju dengan @wingsuitist
Anda tidak dapat melakukan pengujian e2e dengan Cypress dan penyedia pembayaran apa pun yang, seperti yang dapat Anda bayangkan, sangat penting untuk banyak bisnis.

Contoh yang sangat sederhana adalah menggunakan PayPal sebagai opsi pembayaran, tidak mungkin Anda dapat melakukan pengujian e2e dengan integrasi seperti itu saat ini.

Saya benar-benar berharap ini keluar dari kotak juga.
Saya harus mengautentikasi dengan auth0 dan melalui aplikasi kami yang akan memicu masalah dalam masalah ini. Saya membaca artikel auth0 e2e cypress tentang cara mengatur auth. dengan cy.request() tetapi mereka menggunakan grant_type: password yang merupakan sesuatu yang tidak ingin saya sertakan dalam aplikasi saya.

Saya ingin menguji halaman login juga, jadi, untuk melewati batasan ini, saya menggunakan Puppeteer do login dan membuat cookie:

const browser = await puppeteer.launch({ args: ['--no-sandbox', '--disable-setuid-sandbox'] }); // Needed to run inside dockerconst page = await browser.newPage();await page.goto(URL);await page.type('#username', USERNAME);await page.type('#password', PASSWORD);await page.click('.ulp-button');const auth0Cookies = await page.cookies();browser.close();

dan kemudian menjalankan cypress dengan:

await cypress.run({ config: { video: false, env: { auth0Cookies } }})

dan dalam file spesifikasi:

Cypress.env('auth0Cookies').forEach(({ name, value, domain, expires, httpOnly, path, secure }) => { cy.setCookie(name, value, { domain, expiry: expires, httpOnly, path, secure, }); });cy.visit(URL)

Dan oleh karena itu, karena cookie sudah disetel, halaman login auth0 tidak muncul dan saya bisa langsung masuk ke halaman aplikasi dan tidak ada dua domain super, tetapi masih berhasil menguji login dan halaman aplikasi

Semoga ini bisa membantu seseorang :)

Ini bisa berhasil, akan dicoba, terima kasih 👍

Baru-baru ini mengalami masalah ini ketika mencoba menjalankan pengujian Cypress kami secara lokal. Platform yang kami uji menggunakan halaman UI dari dua proyek berbeda, dan kami secara teratur menavigasi antar proyek dalam alur pengguna. Ini hanya menimbulkan masalah ketika kami menjalankan lokal dan mendapatkan kesalahan saat mencoba mengunjungi dua port localhost yang berbeda

Salah satu solusi yang saya temukan adalah menyetel port localhost satu proyek sebagai baseUrl, dan menimpa fungsi kunjungan untuk mencegat panggilan apa pun ke port Anda yang lain. Ini meretas, tetapi mengatasi masalah ini

Cypress.Commands.overwrite( 'visit', ( originalFn, url, options ) => { if(url.includes('localhost:12000')) { cy.window().then(win => { return win.open(url, '_self'); }); } else { return originalFn(url, options); } });

Baru-baru ini mengalami masalah ini ketika mencoba menjalankan pengujian Cypress kami secara lokal. Platform yang kami uji menggunakan halaman UI dari dua proyek berbeda, dan kami secara teratur menavigasi antar proyek dalam alur pengguna. Ini hanya menimbulkan masalah ketika kami menjalankan lokal dan mendapatkan kesalahan saat mencoba mengunjungi dua port localhost yang berbeda

Salah satu solusi yang saya temukan adalah menyetel port localhost satu proyek sebagai baseUrl, dan menimpa fungsi kunjungan untuk mencegat panggilan apa pun ke port Anda yang lain. Ini meretas, tetapi mengatasi masalah ini

Cypress.Commands.overwrite( 'visit', ( originalFn, url, options ) => { if(url.includes('localhost:12000')) { cy.window().then(win => { return win.open(url, '_self'); }); } else { return originalFn(url, options); } });

bekerja untuk saya, terima kasih :1st_place_medal:

@jennifer-shehane dan orang-orang hebat lainnya di tim cemara,

Saya akan naik kereta komentar yang sudah panjang ini dan mendorong untuk ini juga. Kasus penggunaan saya memvalidasi bahwa server node-merah + ui (dilayani pada port yang berbeda dari aplikasi utama) dapat berinteraksi dengannya dan bahwa interaksi tersebut akan mengubah perilaku aplikasi utama.

Saya mendukung apa yang dikatakan @djpasch di atas:

Persepsi saya tentang pengujian End-2-End mencakup aliran bisnis yang lengkap. Tidak hanya menguji front-end dari satu aplikasi.

Sangat setuju

Terima kasih!

Saya juga sangat membutuhkan ini. Tidak ada cara untuk menguji aplikasi web modern tanpa ini. Mereka semua menggunakan Oauth 2.0 dengan PKCE di sisi server klien dan otorisasi, jadi Anda tidak dapat memperbaikinya. Dalam beberapa skenario Anda mungkin bisa tetapi secara realistis Anda tidak akan pernah bisa melakukan ini. Itu hanya rawan kesalahan dan tidak sepadan.

Jadi ya, kita membutuhkan ini!

Sepertinya kasus penggunaan untuk beberapa domain menumpuk, saya ingin menambahkan satu skenario umum untuk itu.
Kami memiliki dua aplikasi, yang pertama adalah yang menghadap ke klien dan yang kedua adalah jenis situs web manajemen backoffice.
Kami ingin menguji skenario lengkap yang berjalan seperti ini:

1. Buat pengguna di 2. aplikasi
2. Siapkan beberapa hal di 2. aplikasi
3. Periksa apakah pengguna dapat masuk ke 1. aplikasi
4. Periksa apakah dia memiliki hak istimewa yang benar di 1. aplikasi
5. Periksa apakah situs webnya memiliki markup yang benar (bersyarat berdasarkan perannya) di 1. app

Menggunakan API alih-alih perayapan web tampaknya sedikit meleset di sini, kami ingin menguji pengalaman pengguna akhir (bagus untuk pengujian regresi setelah rilis baru)

Tim kami saat ini sedang berupaya membuat pengalaman yang lebih baik seputar pengujian autentikasi, yang merupakan kasus penggunaan besar yang tercakup dalam masalah ini. Kami tahu bahwa banyak orang tidak puas dengan pendekatan pengujian otentikasi saat ini secara terprogram dan kami ingin mengatasi masalah tersebut.

Ada beberapa fase untuk mengatasi inti masalah dengan autentikasi pengujian yang akan kami luncurkan sepotong demi sepotong. Kami membaca komentar semua orang dan menggunakannya untuk mengevaluasi cara mendekati pekerjaan di depan kami.

Terima kasih @jennifer-shehane, itu memang use case kami, apakah ada pembaruan/timeline tentang ini?
Apakah mungkin untuk menunjukkan masalah/cabang di mana ini sedang ditinjau, mungkin kami bisa mendapatkan bantuan tentang pengembangan fitur dan mempercepat rilis :)

Saya juga punya kasus penggunaan. Dua perusahaan bergandengan tangan di Belanda 10 tahun lalu. Karena banyak masalah, keduanya merupakan merek yang sangat kuat, mereka memiliki dua domain yang berbeda (A.nl) dan (B.nl). Otentikasi untuk keduanya ditangani pada layanan yang berjalan di domain A.nl. Jadi, jika pengguna ingin masuk ke B.nl, otentikasi mereka ditangani oleh A.nl, maka kunjungan ke B.nl terlebih dahulu membawa Anda ke A.nl yang sekarang ditetapkan sebagai superdomain. Saya sekarang tidak dapat menavigasi ke dan karenanya mengotomatiskan kasus uji apa pun untuk domain B.nl.

Saya harus menggunakan busur derajat sekarang !!!! 🤦 🤦.

Sebelum Anda bertanya mengapa busur derajat, UI untuk B.nl dalam sudut dan tes E2E yang ada semuanya dalam busur derajat / typeScript

Saya akan senang melihat ini diimplementasikan, sampai saat itu kita terjebak dengan Selenium. Berikut kasus penggunaannya:

Tim kami mengembangkan SDK sisi klien yang diintegrasikan oleh pelanggan kami di situs mereka sendiri. Kami juga memiliki dasbor tempat pelanggan kami dapat masuk, mengonfigurasi integrasi mereka, dan melihat aktivitas.

Kami membutuhkan kemampuan untuk menjalankan pengujian yang mengunjungi dasbor kami dan bermain dengan beberapa pengaturan, lalu beralih ke situs pelanggan contoh yang menggunakan SDK kami tempat kami melakukan beberapa tindakan, lalu beralih kembali ke dasbor untuk memeriksa apakah tindakan telah dicatat dengan benar.

@StickyCube Banyak orang telah meminta fitur ini selama lebih dari 3 tahun sekarang dan tampaknya Cypress bukan alat yang tepat untuk pekerjaan itu dalam beberapa kasus sampai ini diterapkan. Saya setuju bahwa itu akan menjadi tambahan yang bagus untuk Cypress, keputusan untuk tidak mengimplementasikannya sangat beropini yang merupakan IMO yang salah. Alasannya adalah untuk menguji setiap lapisan secara terpisah. Jadi dalam contoh Anda, akan disarankan agar Anda menggunakan cy.request untuk mengunjungi dasbor Anda sebagai langkah pertama untuk mengatur pengaturan seperti yang Anda inginkan, kemudian menggunakan permintaan cemara untuk mengatur status situs klien Anda menggunakan SDK dan sebagai langkah terakhir Anda kemudian mengunjungi dasbor Anda di browser untuk memeriksa apakah semuanya dicatat seperti yang diharapkan.

Saya tahu ini adalah cara yang sangat berpendirian untuk memberi tahu seseorang cara menguji tetapi itu tampaknya menjadi inti dari masalah di sini. Saya pikir ini harus diterapkan dan orang harus dapat memutuskan apakah mereka ingin menggunakan API untuk mendorong pengujian lebih cepat atau tidak. Mendorong praktik terbaik itu bagus, tetapi saya pikir pengguna alat harus dapat memutuskan bagaimana mereka menggunakan alat daripada memaksa mereka melakukannya.

Saya mengarahkan pengguna ke pemroses pembayaran di akhir pembayaran.

Saya ingin tes cemara saya mengikuti proses saya melalui itu (itu akan menjadi contoh kotak pasir mereka). Saya ingin memeriksa bahwa mereka selalu diteruskan ke URL yang benar, dan bahwa harga/deskripsi coco*k dengan apa yang mereka lihat di sana, sebagai bagian dari CI saya.

Sama disini. Alur kami melalui proses pembayaran yang terjadi di domain penyedia pembayaran kami tetapi halaman tersebut dirancang dan dikelola oleh kami. Kami menunjukkan banyak informasi terkait pembelian tambahan di sana dan penting bagi kami untuk memeriksa tampilannya dan cara kerjanya. Setelah pembayaran, pengguna diarahkan ke halaman yang menunjukkan kepada mereka apa yang terjadi selanjutnya dengan pembelian mereka dengan opsi tambahan untuk dipilih.

Akibatnya, kami memiliki 3 domain berbeda dan mengejek/mengabaikan salah satu dari mereka tidak terlihat seperti pengujian akhir bagi kami karena kami tidak dapat memastikan bahwa kami memberikan aliran yang lancar dan andal bagi pelanggan kami.

Ini adalah satu-satunya pemblokir yang kami miliki saat memiliki versi berbayar penuh.

Hanya untuk memastikan saya memahami ini, karena saya menghadapi beberapa masalah dan ini mungkin karena skenario ini.
Saya menghadapi masalah CORS sebelumnya, ketika mengatur baseUrl saya ke sesuatu seperti " localhost:4000 " dan api (auth dan yang lainnya) berada di " localhost:3000 ". Dengan hanya mengatur "chromeWebSecurity":false di cypress.json itu akan berhasil

Sekarang saya sedang mengerjakan sebuah proyek di mana saya memiliki aplikasi dan api yang berjalan pada dua wadah buruh pelabuhan berbeda yang diekspos secara lokal di localhost dengan port yang berbeda... Saat saya menjalankan Cypress secara lokal, saya akan memiliki scanerio yang sama persis (keduanya di localhost tetapi pelabuhan yang berbeda).

Sekarang saya mencoba menjalankan Cypress dockerized, dan untuk itu saya harus mengatur baseUrl saya ke " http://webapp " dan apiBaseUrl di " http://api " (itu adalah aplikasi dan url api yang diekspos oleh buruh pelabuhan untuk masing-masing wadah melalui jaringan buruh pelabuhan yang dibuat untuk mereka)

Hasil? Saya dapat mengautentikasi ke aplikasi karena saya memanggil api auth dengan permintaan, dan mengisi penyimpanan lokal dengan token yang diterima... tetapi ketika aplikasi membuat permintaan ke api untuk mengambil data untuk mengisi kotak misalnya, tidak ada datang kembali.

Apakah ini skenario yang disebutkan di utas ini @jennifer-shehane ?

Terima kasih

solusi yang bagus:

Cypress.Commands.add('forceVisit', url => { cy.window().then(win => { return win.open(url, '_self'); });});

Saya mengerti mengapa tim Cypress mungkin menganggap ini sebagai anti-pola, dll. TAPI ada kasus yang sah di mana ini berguna.

Dalam kasus saya, saya sedang mengerjakan ekstensi web yang berfungsi untuk situs web pihak ke-3. Jadi saya tidak memiliki kendali atas situs web atau alur masuk untuk situs web itu. Jadi untuk menguji ekstensi, saya HARUS dapat menghubungkan ke alur masuk di tengah-tengah pengujian yang sedang berjalan.

Anda harus membuka masalah dan memberi tahu kami apa yang Anda coba lakukan!

Saya mencoba menggunakan Cypress sebagai kerangka pengujian ujung ke ujung . Saya ingin Cypress pergi ke back end , melakukan hal-hal di sana, lalu pergi ke front end dan memeriksa apakah semuanya berfungsi. Dan tentu saja saya ingin melakukannya dalam tes yang sama.

Nah itu akan keren jika tim kembali dengan tanggapan resmi untuk ini. Jika ini masalah teknis, saya yakin komunitas bisa membantu.

Sejauh ini tampaknya tim Cypress menganggap ini anti-pola. Tetapi seperti yang ditunjukkan oleh banyak orang di sini, dan seperti yang diketahui oleh pengembang berpengalaman, akan selalu ada kasus yang membutuhkan solusi adhoc. Dan dalam kerangka pengujian, Anda mengharapkan fleksibilitas tergantung pada apa yang Anda uji.

@Pithikos ada di peta jalan karena pekerjaan sedang berlangsung setidaknya sekarang :) https://docs.cypress.io/guides/references/roadmap.html#Upcoming -features

Apakah halaman ini membantu?

0 / 5 - 0 peringkat