-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add exec to ui5 controls to boost performance for data retrieval from many ui5 child controls #456
add exec to ui5 controls to boost performance for data retrieval from many ui5 child controls #456
Conversation
…eval from many ui5 controls
🚀 you're clearly on a 👨💻 spree here @philippthiele 🔋 ¡excellente! |
Hi, nice feature. Good Idea ! Maybe a name like I added some performance testing to your test file. Resulting in roughly bisection of execution time. 👍 for that. |
@dominikfeininger let me know which name fits best to your conventions, I will adapt or you can also do yourself, as far as I know I have enabled edits for maintainers 😊 |
Hi @vobu @dominikfeininger , |
This would help a lot, would be great if this could be merged. 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some node version problems rest looks good. @vobu @dominikfeininger we still want to support node 14, right?
examples/ui5-js-app/package.json
Outdated
@@ -20,7 +20,7 @@ | |||
"test-selenium": "wdio run e2e-test-config/wdio-selenium-service.conf.js" | |||
}, | |||
"devDependencies": { | |||
"@ui5/cli": "^2.14.10", | |||
"@ui5/cli": "^3.1.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ui5 tooling v3 requires at least node version 16. Currently we still need to support node 14 that's why our tests are failing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed, let's put this on a separate PR to both drop node14 and upgrade to ui5-tooling 3
examples/ui5-js-app/package.json
Outdated
@@ -35,5 +35,9 @@ | |||
"dependencies": [ | |||
"ui5-middleware-simpleproxy" | |||
] | |||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do wee need these dependencies?
package.json
Outdated
@@ -74,7 +76,7 @@ | |||
"@types/sinon": "^10.0.13", | |||
"@typescript-eslint/eslint-plugin": "^5.42.1", | |||
"@typescript-eslint/parser": "^5.42.1", | |||
"@ui5/cli": "^2.14.14", | |||
"@ui5/cli": "^3.1.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here we still test wdi5 with node 14 as well
Hi @philippthiele, great work and nice idea! Looks like this could boost up test execution quite a lot. From my point of view technically this looks fine. Just some minor remarks from my side. Documentation, fixing the tests and naming alignment is open I guess. |
viewName: "test.Sample.view.Main" | ||
} | ||
}) | ||
const buttonText = await button.evalOnControl(function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think of dropping the function()
and return
part of evalOnControl()
to look "cleaner" similar to this:
await button.evalOnControl( getText() )
// or
await button.evalOnControl( this.getText() )
// or
await button.evalOnControl( button.getText() )
// ********* | ||
// new approach -> takes ~4.3sec | ||
marky.mark("evalOnControlForListItemTitles") | ||
const peopleListNames = await list.evalOnControl(function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar to my suggestion above:
await list.evalOnControl( getItems().map( item => item.getTitle() )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would even allow to dynamically change the return type, à la
// have an object returned with an embedded array
await list.evalOnControl( { getItems().map( item => item.getTitle() } )
} | ||
} | ||
const peopleListData = await browser.asControl(listSelector).evalOnControl(function () { | ||
return { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just for completenes' sake:
browser.asControl(listSelector).evalOnControl(
{
tableTitle: getHeaderText(),
peopleListNames: getItems().map((item) => item.getTitle())
}
)
@@ -500,6 +500,15 @@ export class WDI5Control { | |||
} | |||
// returns the array of [0: "status", 1: result] | |||
|
|||
//special case for evalOnControl, passed function needs to be converted to string to be passed to the browser | |||
if (methodName === "evalOnControl") { | |||
if (args[0] && typeof args[0] === "function") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would of course then have to change when we change the API
Here are my .02€: 👀 I left some comments on the way the API looks - let's try and reduce it to the bare minimum. Mind you, my suggestions are suggestions only → open to any kind of mods that make 📛 That having said, I'd vouch to change the method name to ✍️ Additionally, and as @Siolto has pointed out, we'd need documentation on this please 😸 again emphasizing that this is a great improvement! thanks for the work you put into this so far! |
@vobu
Rename method to exec: done Documentation: Will do when everything is clarified and implemented 😊 |
ah, of course, didn't have this on the radar!
👍
👍 please also don't forget to downgrade |
@vobu I have update the chromedriver in the package lock which fixed a few tests, rest does not seem to be related to a package or the changes in this PR though. Can you help check what is wrong? Also: I have extended the functionality to accepts arguments as well, as we were talking about anything being possible with a function, passing additional arguments makes sense I would think 😊 Reminder for me: I should check whether propagating errors is possible, to make debugging easier when a browser side error occurs, like calling a non-existent function like "button.getTex()" |
sure, I'll peak and see what I can fix. Let me get back to this as soon as I can.
¡excellente!
absolutely, nothing beats DevX improvements. |
@vobu documentation is added 😊 Finishing line is in sight. Please let me know whether something is missing/can be improved! |
Might be worth to check if a general support of direct injected code into browser scope find it's users. const fn = () => {
// since the RecordReplay API etc. is available a full blown test execution would fit in here
return sap.ui.getCore().byId("container-Sample---Main--Title::NoAction.h1").getText()
}
// this code is in wdi5 and could be provided via eg. `browser.execUI5()`
const result = await browser.executeAsync(function (fn, done) {
done(eval(fn)())
}, fn.toString())
expect(result).toEqual("UI5 demo") -> next PR |
w00t! I'll re-review asap, also pinging @Siolto and @dominikfeininger to glance over. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this. is. so. cool.
there's a small typo (suggest
ed a change).
and i left a hint how to optional test for error messages relayed from browser- to Node-scope, as we have this in a test already.
I'm stoked to see this go in once it has the +1 from Dominik and Simon
|
||
|
||
it("should be able to propagate a browserside error", async () => { | ||
//Log Output during this test should be 3 times: [wdi5] call of exec failed because of: TypeError: this.getTex is not a function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
optional enhancement: you can validate error messages on the console in the Node.js scope with the help of sinon
.
See
const sandbox = sinon.createSandbox() |
expect(buttonTextArrow2).toEqual(regularBtnText) | ||
}) | ||
|
||
it("execute function browserside on button to get its text with fluent sync api, basic return type", async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small typo
it("execute function browserside on button to get its text with fluent sync api, basic return type", async () => { | |
it("execute function browserside on button to get its text with fluent async api, basic return type", async () => { |
this. is. so. cool. |
@philippthiele we'll of course announce the new version with this excellent feature, but would you also care to blog about it on blogs.sap.com? Pretty please? 😸 |
@vobu I will not be able to produce an adequate blog post before my vacation, I will be happy to pick up the topic afterwards 😊 |
all good! enjoy your time off and recharge properly! looking forward to reading your blog post after your vacation 😄 |
Note: documentation is still missing, please let me know what you think of the PR and whether something can be improved, before I start documentation efforts. Thanks!