Live data from Hacker News

Playwright for .NET is now stable

github.com

31–40 of 66 posts

Re: Playwright for .NET is now stable

#31

Earlier quoted context omitted.

Playwright is fantastic, but having used a lot Robot Framework in the past, I would not recommend it even to my worst enemy. The experience he continuous from string / to string conversions that you need to do with the content of the steps and the orrible structure of the directories and the amount of glue code to share some common methods around, brought me to don't even take into consideration job offers that have…

RF does automatic type conversion based on the typehints in the python libraries used. So no need to change types manually. And there is no dictated directory structure. So, stop doing horrible directory structures and the pain goes away. And there is no glue at all needed to share methods at all. Write function in Python/keyword in Robot framework and take it in use using "Resource" or "Library" statement. Done.

test.robot

    *** Settings ***
    Library    calc.py


    *** Test Cases ***
    My First Library
        ${sum}    Plus    1    2
        Should Be Equal As Integers    ${sum}    3
calc.py

    def plus(a: float, b: float):
        return a + b
No manual casting, no extra directories, no complicated sharing of functions.

Re: Playwright for .NET is now stable

#32

Oh, I didn't know this existed. Definitely going to try this. I'm currently using Puppeteer Sharp ( https://github.com/hardkoded/puppeteer-sharp ) and something like: > await page.GotoAsync(" https://playwright.dev/dotnet "); > await page.ScreenshotAsync(new PageScreenshotOptions() { Path = "screenshot.png" }); Is broken, if you have background images in CSS the screenshot happens after Page Load is completed but bef…

you need to put this before the Screenshot ?

await page.WaitForLoadStateAsync(LoadState.NetworkIdle);

Re: Playwright for .NET is now stable

#33
post #22
post #6

Earlier quoted context omitted.

This question does come up quite a lot. One thing the remember is that Cypress is "batteries included" testing framework, where Playwright is essentially just the browser automation part of it. I know the Playwright team is "moving up the stack" and adding many specific testing features, but it's not at the same level (yet?) as Cypress.

I think you're thinking of Puppeteer? Playwright has stuff like automatically waiting for elements, selecting by text etc all built in - with modern JavaScript/TypeScript, none of the weird chaining syntax and debugger. There are also tools that give you pretty much any feature Cypress has on top of Playwright. (Not saying which is better - only that they're both sort of the same slot)

With the latest release, Playwright includes an integrated test runner: https://playwright.dev/docs/next/test-intro

Re: Playwright for .NET is now stable

#35
post #25

For those of you wondering at home: Playwright for .NET is the official language port of Playwright, a Node.js based library to automate Chromium, Firefox and WebKit with a single API.

Still requires nodejs though, it is more a wrapper than a port.

It's not really a wrapper - it's a client in client/server architecture - the difference is important because it means that .NET is a first-class citizen here (like selenium and unlike tools like puppeteer-sharp) and that updates propagate to all languages automatically.

The downside is indeed that you need a "server running".

Re: Playwright for .NET is now stable

#36
post #25

For those of you wondering at home: Playwright for .NET is the official language port of Playwright, a Node.js based library to automate Chromium, Firefox and WebKit with a single API.

Still requires nodejs though, it is more a wrapper than a port.

So what's the point of it then? Why add more layers of unnecessary abstraction? Why don't just use the node.js library then?

Re: Playwright for .NET is now stable

#37
post #17

Earlier quoted context omitted.

I've had some issues with Cypress selectors randomly failing to find matching elements, even though they are clearly present. Like if I run the same script 10 times it goes through ~7 times. I wanted to try Playwright for another application to avoid such issues. And then I was very surprised to get almost the exact same issues with Playwright. Running against a different application with different test cases. Has an…

Were you able to use the DOM snapshots to debug why the selectors did not resolve? Would love to know more.

> DOM snapshots

I should definitely try that the next time I'm working on this issue. Maybe I can get some kind of small example as well if possible. But replicating the problematic conditions is probably hard.

Re: Playwright for .NET is now stable

#38

Earlier quoted context omitted.

Still requires nodejs though, it is more a wrapper than a port.

So what's the point of it then? Why add more layers of unnecessary abstraction? Why don't just use the node.js library then?

Because for some teams it's easier to write tests in plain C# with NUnit/xUnit libs.

Re: Playwright for .NET is now stable

#39
post #35

Earlier quoted context omitted.

Still requires nodejs though, it is more a wrapper than a port.

It's not really a wrapper - it's a client in client/server architecture - the difference is important because it means that .NET is a first-class citizen here (like selenium and unlike tools like puppeteer-sharp) and that updates propagate to all languages automatically. The downside is indeed that you need a "server running".

Nice, just saw there is an official Java and Python version too.

Re: Playwright for .NET is now stable

#40

Oh, I didn't know this existed. Definitely going to try this. I'm currently using Puppeteer Sharp ( https://github.com/hardkoded/puppeteer-sharp ) and something like: > await page.GotoAsync(" https://playwright.dev/dotnet "); > await page.ScreenshotAsync(new PageScreenshotOptions() { Path = "screenshot.png" }); Is broken, if you have background images in CSS the screenshot happens after Page Load is completed but bef…

Have you tried selinium and phantomjs headless ? I was using that a few years ago and it worked very well.

I have built selenium test harnesses using webdriverjs and Jest as the runner at my two most recent jobs. Been using the webdriverjs 4 alpha which has/had been in progress forever. I've never had a flakey-ness issue that was the fault of selenium.

I don't understand why it doesn't get more love and support. You can build higher level testing frameworks right on top of it.

Post reply on HN