This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-30
Channels
- # adventofcode (4)
- # aleph (1)
- # announcements (7)
- # aws (10)
- # babashka (23)
- # beginners (23)
- # calva (20)
- # chlorine-clover (13)
- # cider (17)
- # clj-kondo (13)
- # cljfx (9)
- # cljsrn (9)
- # clojure (98)
- # clojure-australia (1)
- # clojure-dev (15)
- # clojure-europe (127)
- # clojure-nl (4)
- # clojure-sanfrancisco (3)
- # clojure-uk (98)
- # clojurescript (25)
- # community-development (8)
- # core-async (15)
- # cryogen (9)
- # cursive (7)
- # data-science (1)
- # datascript (5)
- # datomic (3)
- # devcards (2)
- # fulcro (5)
- # graalvm (1)
- # helix (8)
- # jackdaw (1)
- # jobs (5)
- # kaocha (17)
- # malli (5)
- # meander (5)
- # off-topic (37)
- # pathom (33)
- # pedestal (3)
- # re-frame (12)
- # reitit (1)
- # remote-jobs (3)
- # sci (1)
- # shadow-cljs (6)
- # testing (1)
- # vim (6)
- # vrac (5)
We currently use etaoin to drive the integration tests for a full stack clojure(script) application. However we have some front end components that use devcards and a bunch of specific UI states etc are tested by triggering synthetic events on these components. These tests were then integrated into CI by using etaoin to point at our shadow-cljs devcards build and verify the devcards UI doesn’t display any test errors. Obviously this is a bit gross; not least because the devcards dom isn’t very semantic (and detecting a test failure in the dom is pretty brittle due to the non-semantic html/css classes etc. Does anyone have any better ideas on how to integrate devcard tests built with shadow-cljs into a CI flow?
I’m guessing compiling the tests with shadow-cljs and using karma to run them is the right way