I love Playwright.
Playwright via nbb has been great. I tend to REPL drive some sanity tests I used to do manually
@gar - Yes, I use it "directly", but through a custom wrapper developed according to current needs
Yes, with nREPL
Y'ever done an nrepl for playwright? Would be cool for LLMs for headless runtime access maybe
Me too ❤️
yes playwright is key to success
@pez for integration testing, or what do you use it for?
Integration testing, yes. Or just that the UI behaves like I want it. It’s great for catching regressions.
Haven't tried it myself. How does it compare to cypress in your opinion?
It has Java API, so you can use it from REPL. Great for TDD. Another part is running the actual page in browser window instead of embedding it in Cypress I was using Cypress for component testing, but it was flaky, hard to maintain and I had to write tests in ClojureScript. With Playwright I bind new browser context with clojure.test fixtures and it's run like any other Clojure tests. Headed or headless mode. @gar - you should definietly try Playwright. For me it was a gamea changer comparing to Cypress
Thanks, @arturangiel ! I'll definitely give it a try. Running like reguler closure tests is very appealing.
@arturangiel: do you use the java-lib directly, or some wrapper?
I think the one thing Cypress still does better is using test timings for sharding. Playwright seems to be mainly using file names and it’s often that one shard is consuming most of the lead time. But locally I run with 13 shards so it’s still pretty fine.
by sharding, do you mean dividing up the tests for parallellization?
Yes.
Does anyone have an agreement with their employer to dedicate a certain amount of time to an open source project? I am thinking of proposing that to my boss, kind of as an alternative to acquiring certifications (which seem like mostly a waste of resources to me)
Really valuable insights, thanks!
Google (and others) have a "20% time" policy for this. I cannot speak to its effectiveness, but there's quite a bit of documentation on it which could be fuel for your negotiations. https://en.wikipedia.org/wiki/Side_project_time#History
If you frame the OSS work you're doing as being beneficial to the company (assuming it actually is), that will make negotiations much easier.
I agree that many (most?) certifications are worthless so doing OSS work as a way of expanding your skills seems like a good approach to me. Where I work, half a day a week (so "10% time") is considered perfectly reasonable -- more if the OSS work directly supports the company. Which basically means I can contribute to any OSS libraries and tools we already use... and there have been occasions where that has meant spending most of a week working on some OSS project issues that we ran into at work. A lot will depend on how your employer views OSS in general. Does your company open source any of their tools/libraries? Does your company heavily depend on specific OSS projects?
At some previous companies, I've had an addendum added to my contract that allows me to work on specified OSS projects without the company having any intellectual property claims over that work. That's something you have to watch out for in some employment contracts, where the company tries to exert ownership over any software you work on while employed, even on your own time.