This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-18
Channels
- # announcements (4)
- # aws (24)
- # babashka (118)
- # babashka-sci-dev (18)
- # beginners (56)
- # calva (2)
- # clojure (54)
- # clojure-dev (8)
- # clojure-europe (25)
- # clojure-gamedev (5)
- # clojure-nl (1)
- # clojure-norway (6)
- # clojure-uk (2)
- # conjure (1)
- # core-async (1)
- # data-science (3)
- # datomic (5)
- # emacs (8)
- # fulcro (4)
- # hyperfiddle (12)
- # interop (1)
- # jackdaw (4)
- # lsp (5)
- # mid-cities-meetup (5)
- # nbb (32)
- # off-topic (21)
- # reitit (5)
- # shadow-cljs (12)
- # sql (8)
- # vim (18)
- # xtdb (9)
Open a bb repl, and
(require '[taoensso.timbre.appenders.core :refer [println-appender]])
It errs with
; : Unable to resolve classname: java.util.concurrent.CountDownLatch user
So it seems like at the current phase we cannot configure the appenders for timbreWhy does that error occur? Are we use some shim layer to bypass the j.u.concurrent package?
Only the core namespace is built into bb. You should not have to include timbre in your bb.edn which is probably what you're doing now
Issue welcome, we could add the appenders ns with the println appender too but as I said earlier, it's already available through the core namespace
@borkdude how pleasant is it to use etoain + babashka? i guess the slow bits would now be between the driver and the browser?
I haven't used it myself much yet, but @UE21H2HHD has been actively working on this
Note that you have to use the master branch of etaoin - there is no tagged release yet
that's for JVM right - i can just use the pod with bb?
good thing i asked 😄
makes sense
Hey ho! Yeah, borkdude and I have volunteered to care for and maintain Etaoin. I've been digging in deep over the past while, I've learned a ton, but would not claim that I am an expert. I have one more issue I'd like to resolve before I cut a release to clojars. As for usage from bb, the fast startup time is really nice, otherwise I haven't really noticed behaviour differences between bb/jvm-clojure (which probably means we've done a good job with bb support!).
huzzah! thanks Lee!
I wanna try it myself on clerk, if @U5H74UNSF agrees
I've been using etaoin on previous Clojure projects as well - aside from the quirkiness of UI tests in general, it's a nice lib to work with.
i've tried browser-driver testing a number of times in the past, i've never had a good time
but never with etoain, though - the pure Clojure impl may just be the ticket!
yeah, it's crucial to design your tests well i expect, probably not something i ever succeeded at 😅
FWIW, the Etaoin test suite seem to rarely fail on chrome/firefox on linux. I did have some test stability challenges on macOS and Windows, which may be somewhat resolved... not sure yet.
But yeah, there are sometimes bugs in web drivers, or browsers, or environmental issues on CI.
browsers amirite
I think playwright & puppeteer enable way more reliable tests thanks to the more powerful capabilities like waitForFunction, see eg https://dev.to/checkly/avoiding-hard-waits-in-playwright-and-puppeteer-272
ahhh interesting
@U5H74UNSF if it's not too much of an imposition, would it be possible to spend 20 mins on a zoom sometime, so you can show me how you're using P+P?
etaoin has similar things afaik, https://github.com/clj-commons/etaoin/blob/master/doc/01-user-guide.adoc#wait-functions
@U0509NKGK I've actually ported some of nextjournal tests (http://nextjournal.com + clerk) to run with #nbb on playwright
mmm i would love to see that
a constraint we're struggling with at the mo is a lack of testing confidence. our whole system of work is great, except when we make foundational changes, and then we get stuck in the mud with lots of poorly organised manual testing. looking for leverage
but I did this at a time when nextjournal wasn't aware of the Java API in playwright.
ok interesting! nbb is bb + node right (i'm such a node noob)
I think you could accomplish "wait until the reframe queue is full by evaluating some JS in the client" can also be accomplished with etaoin, so I'm not exactly sure what benefits playwright will give you
playwright and puppeteer have more direct access to the browser runtime iirc, so you can wait until a function returns true and then wait two more js frames until it's rendered by react
I also asked to the organizer of ClojureD who is working on a browser testing project for clojure, what his thoughts on playwright was and if he was using it: his reply was, well it isn't a standard, I'm sticking with selenium/webdriver for my stuff. I guess everyone has different trade-offs.
our testing needs with content-editable stuff on the nextjournal editor are also pretty demanding, certainly not your standard use case
One could argue that you're testing on a fairly low level, lower than normal end-to-end tests operate on.
the content-editable stuff must surely set your hair on fire
I mean, by inspecting the re-frame queue in a test, you're not running the test in terms of "now the user does this, than that, and then I see this"
do some interaction, wait the minimum amount of time until those changes should be propagated to the dom (without any timeouts), then fail or succeed.
to be fair, we still see occasional flakes on CI so it's not perfect. But it's the best testing environment in the browser we've used and we've been trying for a while. Selenium (which then got standardized into webdriver) is crap in comparison imo.
thanks for the input fellas, appreciate it!
FWIW, while doing some research for Etaoin I was digging around Selenium content and stumbled on the fact that a https://github.com/w3c/webdriver-bidi is under development. Might bear some interesting fruit someday.
interesting, though most (all?) of the things https://github.com/w3c/webdriver-bidi/blob/master/explainer.md#goals are possible today with puppeteer & playwright
............ yet 😆
it should actually: #babashka can you http, json & websockets, right? Should be all that’s needed: https://chromedevtools.github.io/devtools-protocol/#endpoints
There is this project which works with bb. Does that mean it can integrate with playwright? https://github.com/tatut/clj-chrome-devtools
I think so, in Chrome at least https://github.com/microsoft/playwright/issues/4862#issuecomment-754944818
playwright is basically the same as puppeteer (heard it was even created by some of the same folks that moved from google to microsoft) but also working in Safari & Firefox using custom builds of those browsers with the patches above
I know but the Playwright APi is Java so you would have to rewrite all that stuff in bb right
not sure how much https://github.com/tatut/clj-chrome-devtools differs from the puppeteer / playwright api, maybe it’s already sufficient
Fair enough. Here is an example. https://github.com/tatut/clj-chrome-devtools/blob/master/test/clj_chrome_devtools/chrome_test.clj
I guess the part you would need to figure out is how to talk to a playwright-instrumented/patched browser without using the playwright API.
Sure, I mean the logistics of getting playwright to download a browser, spinning up and then talking to it. Maybe it's easy, maybe not. Worth a shot
also care less about playwright vs puppeteer, they're almost the same. It's nice to be able to also run in safari & firefox but not a deal breaker.
lol, I screwed up my local Chrome install by executing:
$ node_modules/playwright/bin/reinstall_chrome_stable_mac.sh
+ rm -rf '/Applications/Google '
Got something working:
((requiring-resolve 'babashka.deps/add-deps)
'{:deps {tatut/devtools {:git/url ""
:git/sha "cc96255433ca406aaba8bcee17d0d0b3b16dc423"}
org.babashka/spec.alpha {:git/url ""
:git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}}})
(ns
(:require
[babashka.process :refer [process destroy]]
[clj-chrome-devtools.automation :as auto]
[clj-chrome-devtools.core :as core]))
(def proc (process "/Users/borkdude/Library/Caches/ms-playwright/chromium-930007/chrome-mac/Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222"))
(let [browser (auto/create-automation (core/connect))]
(try
(auto/to browser "")
;; NPE:
;; (prn (auto/text-of "body"))
(finally
(destroy proc))))
So I'm launching the browser installed by playwright with a specific debugging port which clj-devtools can then connect toI’m frankly a little bummed having just spent a ton of time on Etaoin (borkdude and I volunteered to maintain it), but good to learn about issues and alternatives to webdriver! Thanks @U5H74UNSF! I’ll likely add a note to Etaoin’s “interesting alternatives” section.
@UE21H2HHD There's plenty of etaoin users and I've used it with satisfaction in the past
And I'll probably keep using it for new projects (like scittle), since I can now use it with #babashka :)
Yeah, I’m using it to generate contributor badges for READMEs. Great for stuff like that too.
I'm also using it for my watch script for bb book, to re-render the rendered book in the browser while developing
(still on the pod here, but will switch over: https://github.com/babashka/book/blob/master/script/watch.clj)
Also using it for testing https://borkdude.github.io/re-find.web/: https://github.com/borkdude/re-find.web/blob/master/test/re_find/web_test.clj
I probably don't write sophisticated UIs enough (like http://nextjournal.com) to experience any of the downsizes ;)
There is a section in docs listing companies using Etaoin, but adding other more specific example usages would also likely be helpful to folks…. I’ll likely do that.
http://grep.app will probably show more repos using it
Got a minimal thing working here. @U11SJ6Q0K came back with the solution, needed the reset!
https://gist.github.com/borkdude/627be1593c0abe20d5c53caf6aa34d85
Note that text-of
sometimes complains with "no element with that id", I think maybe due to having to wait for it to appear or something. Note sure how to do that, but voila, it seems possible to re-use a playwright-downloaded browser with this library and bb.
I'm looking to run a figwheel
process and a postcss
process at the same time. The CSS process is just a file watcher. I want to be able to interact with figwheel
as I normally would. I'm good with the CSS logs being interspersed between the figwheel logs. I also want to kill both processes when the terminal gets the ctrl-c.
would sh
or processBuilder
be the right choice for this? :thinking_face:
@U6GNVEWQG bb tasks has a solution for this:
{:tasks {
figwheel (clojure "-M:figwheel")
postcss (shell "npx whatever")
-dev {:depends [figwheel postcss]}
dev {:task (run '-dev {:parallel true})}
}}
oh lord. I can't believe I missed that :face_palm:. Sad that I overcomplicated just an obvious thing 😞 Thanks!!
docs are here: https://book.babashka.org/#parallel
Q: is there something like Enlive or Enliven in the bb world? I have a html website that I want to use as a template
maybe Enlive already works with bb but its a stagnant project so I’m wondering if there’s a modern take on it
I’m also planning to use https://github.com/ptaoussanis/tempura . Is this known to work in bb land?
I see neither of these libs in https://babashka.org/toolbox/ hence the questions
I’m fine with using these libs in jvm Clojure but I always try bb first these days 🙂