111–120 of 149 posts
Earlier quoted context omitted.
I'm exaggerating but Playwright vs Puppeteer is a bit like comparing Puppeteer with Selenium
Not at all true
What do people thing of playwright vs cypress? I've been considering using playwright instead as it supports more browsers and I feel like it's easier to do production monitoring (by putting it in a aws lambda or using checkly) - Cypress: https://www.cypress.io - Playwright aws lambda: https://github.com/PauloGoncalvesBH/running-playwright-on-aw... - Checkly: https://www.checklyhq.com
We see a strong adoption of Playwright. It’s the default we recommend to users now. We also support Puppeteer, but its development is lagging. Having said that, I would love to support Cypress if I had infinite time and focus. Side note: Selenium is not on the menu, even with its large install base. We are aiming for where the puck is going and it’s going to Playwright. Full disclaimer: I’m CTO at Checkly.
Are there any products for QA folks that reduce the workload? I find most things are still done manually…
Earlier quoted context omitted.
I'm sorry if not clear, but I was asking about the WebDriver spec [1]. The terminology gets confusing because WebDriver was a tool that then merged with Selenium and Selenium implemented the WebDriver wire protocol. If Playwright isn't using WebDriver, is there a new browser automation API? Edit: It looks like it's using Chrome's DevTools protocol. I'll have to read up more on that. I thought Google deliberately didn…
I'm not sure if it's using (or can use) CDP for all automation or for chromium, but CDP became my go to for headless browser work in the last six months, it's bypassing the abstraction of puppeteer and has a lot more language support. But it's not itself a test framework, nor is puppeteer, so it's nice having a more modern toolset on top.
"WebDriver Bidi is the next generation of the W3C WebDriver protocol and aims to provide a stable API implemented by all browsers, but it’s not yet complete. Until it is, Selenium provides access to the CDP for those browsers that implement it (such as Google Chrome, or Microsoft Edge, and Firefox), allowing you to enhance your tests in interesting ways."
https://www.selenium.dev/documentation/webdriver/bidirection...
Earlier quoted context omitted.
Thanks for the suggestion. How would this work with GPU-bound machine learning models? The model processing takes > 30 seconds and would still represent the bottleneck?
You would still have the same bottleneck but the API request would return straight away with some sort of correllation ID. Then the workers that handle the GPU bound tasks would pull jobs when they are ready. If you get a lot of jobs all that will happen is the queue will fill up and the clients will wait longer and hit the status endpoint a few more times. Here is an example of what it could look like: https://docs.…
Right now, we use ELB (Elastic Load Balancer) to sit in front of multiple GPU instances.
Is this sufficient or do you suggest adding Celery into this architecture?
Earlier quoted context omitted.
Consider us one. :) We tried removing "async" -- thinking it would force sequential processing -- but it unexpectedly seemed to cause parallel processing of requests, which caused CUDA memory errors. Before removing "async", this is the weird behavior we observed: * Hacker blasts 50-100 requests. * Our ML model processes each request in normal time and sequentially. * But instead of returning individual responses imm…
Python async is co-operative multi-tasking (as opposed to per-emptive) There is an event loop that goes through all the tasks and runs them. The issue is the event loop can only move on to the next task when you reach an await. So if you run a lot of code (say an ML model) between awaits no other task can advance during this time. This is why it is co-operative, it is up to a task to release the event loop, by hittin…
Right now, we use ELB (Elastic Load Balancer) to sit in front of multiple GPU instances.
Is this sufficient or do you suggest adding Celery to this architecture?
Earlier quoted context omitted.
I'm not sure if any of these are pertinent to your tests, but these are the issues I see most often that cause flaky tests: - Hard-coded waits in your code, like "Thread.sleep(1000)". A better alternative is to replace hard-coded waits with something that waits for an element or value to appear on the page. i.e. click on a button and wait for a 'Success' message to appear. Puppeteer and Playwright both have good cons…
> - Hard-coded waits in your code, like "Thread.sleep(1000)". A better alternative is to replace hard-coded waits with something that waits for an element or value to appear on the page. We don't do any timed waits, all of our waits are for an element or value to appear, but these waits never complete sometimes, non-deterministically. We then added a long 5 min timeout on these waits because we know the test will nev…
I'm not familiar with it specifically, but that's my go-to starting place in weird automation issues like that. Normally it gives some kind of hint as to why that's happening (or why Selenium thinks it's happening).
Earlier quoted context omitted.
I'm not sure if any of these are pertinent to your tests, but these are the issues I see most often that cause flaky tests: - Hard-coded waits in your code, like "Thread.sleep(1000)". A better alternative is to replace hard-coded waits with something that waits for an element or value to appear on the page. i.e. click on a button and wait for a 'Success' message to appear. Puppeteer and Playwright both have good cons…
> - Hard-coded waits in your code, like "Thread.sleep(1000)". A better alternative is to replace hard-coded waits with something that waits for an element or value to appear on the page. We don't do any timed waits, all of our waits are for an element or value to appear, but these waits never complete sometimes, non-deterministically. We then added a long 5 min timeout on these waits because we know the test will nev…
Earlier quoted context omitted.
My main issue with Cypress was the fact that it required a shift in mental model, i.e. queuing commands rather than executing them, thenables that aren't actually promises, running as client side JS as opposed to in a controller script. There were a ton of sharp edges and required a lot of education to adopt. Meanwhile Playwright's API is just promises. Everybody knows how to compose promises. The Cypress approach do…
The irony is that the Cypress model is extremely similar to the Selenium Version 1 model. We abandoned that approach in Selenium V2 (WebDriver). Time is a flat circle.
What do people thing of playwright vs cypress? I've been considering using playwright instead as it supports more browsers and I feel like it's easier to do production monitoring (by putting it in a aws lambda or using checkly) - Cypress: https://www.cypress.io - Playwright aws lambda: https://github.com/PauloGoncalvesBH/running-playwright-on-aw... - Checkly: https://www.checklyhq.com