71–80 of 133 posts
Puppeteer is really really good. I just discovered it and used it for something and it’s a blast to work with. I’m seriously thinking there is a cloud api play in the near future — a puppeteer Page is a pretty awesome container format ... a Puppeteer Page or BrowserContext per request would provide an awesome cloud-function-like programming model I think...
I also used to build a desktop app that my team uses to download Alexa Flash Briefing metrics (because there's no API for that)
Puppeteer's full-screen screenshots & DOM manipulation abilities are clutch!!
Earlier quoted context omitted.
I have never heard of TestCafe, but I've used Puppeteer for a variety of projects with Chrome. My latest one was using it to convert HTML files into PDFs en masse.
Is there an advantage to that approach over the more direct wkhtmltopdf?
Earlier quoted context omitted.
If it really E2E from user perspective you shouldn't doing any magic and manipulate POST data.
You're not technically wrong, but unit/integration/E2E are not hard categories for tests, they're just points along a continuum. Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is, so it becomes much less useful as soon as you're t…
Selenium/WebDriver isn't a testing tool. It's a a W3C protocol for remote control of web browsers. I think once you get over that misconception, selenium starts to make a lot more sense.
Earlier quoted context omitted.
You're not technically wrong, but unit/integration/E2E are not hard categories for tests, they're just points along a continuum. Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is, so it becomes much less useful as soon as you're t…
> Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. If you're building a SPA, you can mock out the backend and control the backend mock behaviour in your Selenium test.
If you want to do something like request interception, you have to point your front-end at a proxy server and mock things there. If you want to test a file upload, you have to simulate typing into the dialog and then use a literal file on the disk. It's just pointless friction for most testing setups.
It's not that E2E testing is bad, it's that in some projects there's room for a Selenium-style tool across the entire spectrum from E2E testing to unit testing; particularly if I'm testing something like D3 code, or parts of a CSS layout.
It's all doable, it's just that Selenium makes it all needlessly difficult, because its point-of-view is that your front-end should be treated mostly like a black box, and that any mocking that does exist should be happening via endpoints and application connectors.
I like Selenium -- I prefer using an Open protocol over Puppeteer. I just feel like that protocol could use a lot more design work.
For what I see, puppeteer is very much like testcafe (able to run with headless/full Firefox, Chrome, Edge ..., but testcafe doesn't need a custom-built Firefox). TestCafe can run javascript code on the page and return the data back, that means it can be used to get data in POST requests. It can take screenshots too. If anybody is familiar with both tools, could you please what this tool can do but the other cannot?
Earlier quoted context omitted.
You're not technically wrong, but unit/integration/E2E are not hard categories for tests, they're just points along a continuum. Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is, so it becomes much less useful as soon as you're t…
>This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is Selenium/WebDriver isn't a testing tool. It's a a W3C protocol for remote control of web browsers. I think once you get over that misconception, selenium starts to make a lot more sense.
If I'm remote-controlling a browser over a network, wouldn't I occasionally want to send it an arbitrary file upload? Why do I need to separately transfer the file using a different service, and then refer to it with the disk path?
The only reason I can think of is, "normal users couldn't do that." But normal users also can't control a browser over a network. There's no reason to restrict a control protocol to only things that normal users can do.
For automated testing, why Puppeteer instead of Selenium?
Much better access to low-level information. You can hook (and mock) requests, see what POST data was sent and basically do lots of magic. Also, my experience with Selenium under Python is that doing anything bigger quickly turns into one giant timing hack.