We are currently updating our linting to match the Front End Developers’ idea of linting. Mostly because they want to be able to look at and understand our testing code. We are all working in JavaScript.
No big deal… or is it?
We have found, in our “old way” of doing WDIO “Describes” and “Its” that we could simply use an unnamed function, and it simply worked.
it('No Place Like Home', async function () {
We have started updating to the arrow functions, which, on the surface, “look the same(ish)”, but don’t work the same.
Our problem comes with the usage of “this”…
We are using a method of “retry”, and we set the number of retries in our config file. In some of the tests, we need to know if the current run is the first run, or the first retry.
To do this, we grab this.wdioRetries which will tell us “0” for primary run, or “1” for first retry, or “2”, for the second retry, etc.
Wouldn’t you know it? The “unnamed function” lets us use “this” without trouble. The linting gives us a warning about “no unnamed functions”…
When we convert it to the “arrow function”, we get “this.wdioRetries === undefined”. “this” doesn’t exist in the scope of the arrow function. But the linting LOVES the arrow function, even though the test now fails.
We also, at times, need to override certain test values, like default timeout. Which we can’t do without access to “this.test”…
So. The question is, how do we get “this” in an arrow function? Is there a way to pass it in? A way to call it in by another way (process, browser, driver…)? Some built in function to make a call (const thing = whatever.getThis())?
Or, is it futile? We should stay with the unnamed functions?
I’ve tried:
it('No Place Like Home', async () => {
it('No Place Like Home', async (this) => {
it('No Place Like Home', async this => {
I’ve tried simple functions, etc. The problem is the scope, which needs to be at the TEST level, not GLOBAL.
Hoping someone else has blazed this trail before me and has found the solution.