Open mrudolf-udina opened 8 months ago
first of all, thanks for the very detailed description of your issue 👍 we've seen similar behaviour in UI5 apps where an OData endpoint is continuously polled, causing ongoing async requests, resulting in the UI5 lifecycle to never complete. To circumvent this, "exclude" the URL that is continuously polled from the UI5 lifecycle via https://ui5-community.github.io/wdi5/#/configuration?id=ignoreautowaiturls
For those facing the same problem:
The problem was that wdi5 couldn't be properly injected into the browser. The solution for this is to add the following lines of code into the test.js spec file:
add to the very first line:
const { default: _ui5Service } = require("wdio-ui5-service")
const ui5Service = new _ui5Service()
and before all tests, add:
await ui5Service.injectUI5()
which does the trick and asControl() can be used now!
@mrudolf-udina great that you could resolve the issue! Your solution seems to be a workaround for a more underlying issue because with our standard authentication options you should not have to injectUI5
manually again.
Your sample you shared seems like an application you use inside of SAP. As we are not SAP employees do you have a reproducible example which we - as externals - can use?
after some thinking, I feel that I got to the root cause of things:
when basic auth is used in wdi5
, and basicAuthUrls
is different from baseUrl
, the wdi5
injection gets obliterated.
Here's how that happens:
wdi5
navs to the app under test (baseUrl
)wdi5
correctly gets injectedwdio
gets into the driver seat: it navs to the url to auth against (basicAuthUrls
)wdio
navs back to the app under test (baseUrl
) →wdi5
here, as basicAuthUrls
lives on a different page than baseUrl
thus the need to re-inject wdi5
as @mrudolf-udina explainedEssentially I believe this is a bug 🐛
hey 👋 - silence for 30 days 🤐 ... anybody? 😀
hey @vobu after looking at our code and your thoughts:
after successful auth, wdio navs back to the app under test (baseUrl) → no more wdi5 here, as basicAuthUrls lives on a different page than baseUrl thus the need to re-inject wdi5 as @mrudolf-udina explained
this is happening here exactly after we are finished with the whole authentication part. That is why I am so confused that another injectUI5
is needed
Describe the bug When trying to use wdi5 for our shop, using any asControl() function runs either into an error saying "all of _getControl() failed because of: Error: waitAsync is already running and cannot be called again at this moment" or "Cannot read properties of undefined (reading 'waitForUI5Options')", which is kind of random what error message pops up and causes the test case to fail.
To Reproduce Steps to reproduce the behavior:
After cloning a copy of the shop from the dev branch to VS Code, the following steps need to be done
npm i
cf install-plugin DefaultEnv
cf login -a https://api.cf.eu10.hana.ondemand.com -u [EMAIL] -p '[PASSWORD]'
cf default-env udina-commerce-approuter
npm init wdi5@latest -- --js --baseUrl http://localhost:8080/backend/sap/opu/odata/udina/commerce_srv/$metadata --configPath test/ --specs ./test/specs
data-sap-ui-theme="sap_fiori_3"
ui5 serve
in one terminalnpx wdio run test/wdio.conf.js
or add a script to the package.json file"wdi5": "wdio run test/\\wdio.conf.js"
and run the scriptExpected behavior The test should click on the button and be redirected to the new page
Logs/Console Output waitAsync error:
waitForUI5Options error:
Screenshots
Runtime Env (please complete the following information):
wdi5/wdio-ui5-service
-version: 2.0.6UI5
version: 1.120.4wdio
-version (output ofwdio --version
): wdio : Die Benennung "wdio" wurde nicht als Name eines Cmdlet [...]node
-version (output ofnode --version
): v20.11.0Additional context Other context about the problem:
the target browser is started with
"--no-sandbox"
the code for the sample.test.js selector was created via the UI5 Journey Recorder and several different selectors were tested but all of them caused the same errors