*** 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.> 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"
},
});The downside is indeed that you need a "server running".
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.