*** Settings ***
    Library    calc.py


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

    def plus(a: float, b: float):
        return a + b

> 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 before all CSS images are loaded so you end up not getting backgrounds in the screenshot. The only solution is to try add a delay before taking the screen grab, and it there's any sort of latency then the delay could result in not getting a good screenshot...

It's an amazing piece of software for a domain that was kept on the side of the road for years.

If you already tried Cypress, then it's Cypress but with true multiple browser support, available in 4 languages, without the bloat and a cleaner and more idiomatic API.

Not trying to downplay his project cos it’s actually really good.

await page.WaitForLoadStateAsync(LoadState.NetworkIdle);

Selenium is a source of constant bugs and misery - it's truly a waste of time maintaining its usage in a codebase because randomly sometimes tests fail. The C# wrapper for it is even worse, as it does not follow the idioms of C# and is a straight 1:1 port from the Java version. Highlights include getting exceptions from properties when you hover over them during debug in Visual Studio.

rerunning tests because always a few of them fail on first run

but I noticed that the biggest reason was that often my browser was a little ahead when it comes to version than engine, and after updating both of them the situation was a kinda better.

Anyway I don't recommend Selenium, it wastes too much time

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.

  #Install Chrome for Puppeteer: 
  RUN curl -LO https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
  RUN apt-get update -y
  RUN apt-get install -y ./google-chrome-stable_current_amd64.deb
  RUN rm google-chrome-stable_current_amd64.deb 
  ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
  ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome-stable

  browser = await Puppeteer.LaunchAsync(
                        new LaunchOptions {
                            //If we're debugging, then open actual chrome:
                            Headless = !Debugger.IsAttached,
                            Args = new string[] {
                            "--no-sandbox"
                        },
                        });

https://github.com/puppeteer/puppeteer/issues/4046

https://github.com/microsoft/playwright-dotnet/issues/1076

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

JavaScript as a server-side technology sucks. It was cool back in 2010 when NodeJS first came out and event loops were all the rage. But .NET is now 10x faster than NodeJS, statically typed, has better community support, better tooling, broader official libraries, better package manager, and as a bonus it's not JavaScript. The productivity and performance of .NET with Visual Studio is just unmatched.

Also regardless of keeping it in a _single_ language or tool, one might prefer to write tests in a .net language instead of js or python.

But yes, spending my weekends learning a new language and library is not a feature.

I'd much prefer to spend my off time learning more about my target users, how to better manage a team, or the legal regulations surrounding the domain I'm writing code in, or just hitting the gym...

Not to mention as soon as I add a new language to our project stack that means every current dev has to learn a new technology, our build pipeline becomes more complex, we need a second set of coding guidelines, and finding new devs becomes more difficult because they'll need to know 2 languages instead of one or we have to increase the onboarding time for every future dev who roles onto the project.

I think it's uncommon that it's worthwhile to invest in a second language/tech stack on a real project.

Personally, I work with both C# and JavaScript, and I'd happily use the C# version of Playwright to write and run UI tests.

Don't know, everyday I see more and more C# devs preferring Typescript for new projects.

But for the backend (APIs, services, whatever), I'd personally still go with C# any day - it really is a wonderful language, and the available tooling is fantastic.

Why do You think that this will somehow limit people ability to learn or even make them worse version of them?

Most of the dev's I know, want to do coding for life: - not learning tools from scratch every few weeks, because of the abandoned library - not fight with npm audit every week - not waiting for 5 minutes for webpack to download internet and build project in CI, while .Net builds are already completed, unit tested and waiting for smoke run.

And Java has always been open source.

What's the alternative? Prepare the backend via exclusive frontend operations? That has its own issues like possibly being impossible (e.g. maybe making an admin isn't exposed to the webapp) or being slow, or not being able to create data in a "legacy" state that the current frontend can't do.

Or maybe use C# to create and teardown the data, but then call out to a nodejs process in the middle of the test?

I am legitimately curious how you would test a C# app exclusively from nodejs.

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 anyone else had issues like this with React applications? It's very annoying to not be able to write repeatable tests.

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.

Cypress is more limited compared to Playwright such as multi-domains aren't supported, multiple tabs, or popup windows. For my tests that require that I am using Playwright and for the rest I am currently using Cypress. But I do think the test writing experience is better with Cypress :)

I am considering to move to Playwright for everything now with the new Trace Viewer (https://playwright.dev/docs/debug#playwright-trace-viewer); and contribute to that.

Thankfully this is being actively worked on: https://github.com/cypress-io/cypress/issues/944#issuecommen...

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.

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)

I work at Microsoft but at a completely unrelated team and while I know some of the folks who work on playwright I have no official affiliation and my opinions represent my own and not my employer's.

Playwright is great for this sort of thing! All we do is run the same test with two variants (before/after the change) and run a student t-test (well, a welch t-test but close enough).

It's ±50 LoC and as long as you're fine with running the test enough times to get statistical significance Playwright works quite well for this

If you want to get a sense of how far the system can scale, you would be better with a proper performance testing framework that can run multiple threads, ideally from multiple locations (to avoid any network limits) and built-in support for accurate timing. Apache Bench is pretty common and relatively easy to setup and use. There is also JMeter and even SaaS services to do it for you.

For most real-world performance tests, you should be adding plenty of delay. The average delay on the web between pages for real users runs around 50 seconds, last I looked (which was a while ago, admittedly).

If your app uses keepalives, or polling, or websockets, running your users really fast is going to make your test less accurate and you may get a false positive.