-
-
Notifications
You must be signed in to change notification settings - Fork 750
-
There is one thing I don't really understand.
I.say(...)
returns a Promise<any>
, however, in all the code examples that I can find, there is never ever an await
in front of it. May I ask why? Is it a correct / recommended practise not to await
I.say(...)
? Does it impact test results?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment 1 reply
-
hey @ebi-j I suppose that purpose of that method is just printing something in your logs to make it clearer or something, nothing would be returned when calling that method, also await or not won't make any different, I guess.
Beta Was this translation helpful? Give feedback.
All reactions
-
It actually kind of making some differences in my codebase, and I'm confused about it. I feel like when I don't use await
, and then I.say(...)
is kind of occupies a small block of time, which potentially hide some smelly code, like, when I don't use await
, some of the code runs fine, but when I start using await I.say(...)
, some bits start broken, because the element the test checks is not ready, I have to add I.waitForElement(...)
to make the tests working again.
Another difference is that when I don't use await I.say(...)
, I seldom see UnhandledPromiseRejectionWarning
when I run all the tests, but once I add await
to all I.say(...)
in my codebase, those improperly implemented async
methods start giving me UnhandledPromiseRejectionWarning
and it actually blocks some of my workers from running the rest of the tests.
Beta Was this translation helpful? Give feedback.