-
Notifications
You must be signed in to change notification settings - Fork 291
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
Puppeteer keeping the tab open #276
Conversation
This new feature gives the option to run tests in the same tab and browser without closing either hence avoiding any timeouts.
Hello @hors04, tests are not passing, could you fix it? |
Hello , I've fixed the errors but there seems to be this one new error that says it can't read the property of a variable that I've already added to "jest-puppeteer.config.js" , file which is "keepTabOpen" . It works on my puppeteer package that I use with my tests though. I don't know at the moment what the problem is so it may take a while since I've got other work to do. |
OK @hors04, anyway we can't merge it if tests are not passing. So we have to wait. |
@neoziro Hello again , so I finally fixed the code. The feature of keeping the tab open works only for the default mode. |
@hors04 thanks, I will try to work on it soon. I have to change things before merging it. |
Hi @neoziro, when will this be merged please? |
Any update on this? Would cleanup my test flow a lot 🙂 |
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.
The code looks a bit complicated. I don't want to merge something not stable.
await this.global.jestPuppeteer.resetPage() | ||
} else | ||
if (config.browserContext === 'default' || !config.browserContext) { | ||
this.global.context = await this.global.browser.browserContexts()[0]; |
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 await?
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.
Await is unnecessary. I may have kept it initially for testing purposes.
} else | ||
if (config.browserContext === 'default' || !config.browserContext) { | ||
this.global.context = await this.global.browser.browserContexts()[0]; | ||
const [pageOne,] = await this.global.browser.pages(); |
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 "," ?
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.
browser.pages() returns an array of pages, so we'll always need the first page/element/tab/ default tab that is required to open chrome, the one where the test is run within.
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.
So why adding a "," if you only need the first one?
@hors04 can you please fix the code? |
Any news on this please? |
This new feature gives the option to run tests in the same tab and browser without closing either hence avoiding any timeouts.
Summary
The point of this added feature is to have an option which lets multiple tests run in the same tab. We have about 19 tests which would run in a separate tab one after another(--runInBand), but because of the different tabs ( perhaps something to do with the cache of the browser) the information will get lost in the process and the tests would timeout. This would happen for a random number of tests.We also use docker to run all the tests, not just by terminal.
Test plan
I ran 15 tests for this example because the other 4 can't be used at the moment. A colleague is working on a bug which involves elements used in those 4 tests. I ran the "jest --runInBand , , ..." command in VS Code terminal to demonstrate the output.
This is the result using the same tab where 4/5 tries were successful and one try failing due to the timeout:
This is the result using the same tab where 5/5 tries were successful:
Note 1: The higher the number of tests , the higher the chance of multiple tests failing due to timeout.
Note 2: When the tests are run by docker , the chance of multiple tests failing is even higher.