Open baronfel opened 5 years ago
I havent seen it. It doesn't share the same API as selenium, so using it in canopy would mean creating a wrapper around it that does implement the selenium Interface so that it could just plug right in.
It may be as good as selenium but I am unsure if it would be better. Modern selenium is an ISO spec and the individual browser vendors create a driver that implements the spec, and then they do all the heavy lifting in the browser.
This could maybe have more features (like the PDF generation) though.
I will also add that selenium gets a lot of hate, but its not well earned. (edit)
UI automation is a huge PITA, and Selenium is kind of a PITA, but I've found that ~90% of the time you have subtle bugs in your code that its finding for you, 'randomly', or you need to make some small improvements to your html to make it more testable.
Selenium is also 'fast' in the sense that all it does is make an http request to the browser, so any slowness would be due to the browser (unlikely cause they are fast as hell), and mostly likely due to call times of your pages/api/slow js on your page/too much css.
Oh I don't disagree on either count, personally. I could have left the editorializing off a bit I suppose :) I'm mostly just coming off the tails of some frustrations testing our site! I raised this mostly because I've seen some folks swear by puppeteer and I thought it might be nice to adapt canopy's DSL into that system as well.
You could totally create a nice F# dsl for puppeteer.
the DSL aspect of canopy is nice, but the real secret sauce is the 'stabilization' part that goes to great length to make the code you think/write be as close to 1 to 1 with what is happening behind the scenes. Thats where selenium falls short, its too strict and robotic.
Also, if you would like to start an F# dsl for puppeteer, I would be glad to help you!
You could totally create a nice F# dsl for puppeteer.
the DSL aspect of canopy is nice, but the real secret sauce is the 'stabilization' part that goes to great length to make the code you think/write be as close to 1 to 1 with what is happening behind the scenes. Thats where selenium falls short, its too strict and robotic.
this stabilization piece has me interested
I opted for Puppeteer in my new project, just to get hands dirty with new tool, and it's a disaster. Extreme verbosity, state-of-the-art "f.ck intuition, let's make it from first principles" approach. It might take a day to find a way to click on 4 buttons on page. You can't click on control after testing css path in browser console because "click gets blocked somewhere, it's error on your site". So you end up with something like
const el = (await page.$$('.className'))[0]
await page.evaluate(e => e.click(), el)
while in Canopy it would be
click ".className"
NodeJS itself is not as bad as I was afraid of, it's almost like F# for schoolchildren. But Puppeteer is terrible.
Oops, one vote for Puppeteer (no need for array), overall mark stays the same:
const el = await page.$('.className')
await page.evaluate(e => e.click(), el)
vs
click ".className"
Playwright is available for .net.
Puppeteer is a chrome/chromium-only driver library, for which there is a .net port available at https://github.com/kblok/puppeteer-sharp. It looks like it would be easily portable over to canopy, and seems to be relatively stable/more stable(?) than selenium. Have you seen this before?