This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (35)
- # babashka (31)
- # beginners (77)
- # biff (23)
- # calva (1)
- # clj-kondo (4)
- # cljsrn (3)
- # clojure (71)
- # clojure-dev (9)
- # clojure-europe (51)
- # clojure-france (3)
- # clojure-germany (1)
- # clojure-nl (3)
- # clojure-spec (9)
- # clojure-uk (42)
- # clojurescript (24)
- # clojureverse-ops (3)
- # component (16)
- # cursive (1)
- # data-science (8)
- # emacs (1)
- # fulcro (5)
- # graalvm-mobile (1)
- # graphql (2)
- # honeysql (36)
- # leiningen (3)
- # malli (3)
- # off-topic (16)
- # remote-jobs (1)
- # sql (3)
- # testing (19)
- # tools-deps (11)
- # xtdb (20)
I have a
.cljc file with reader conditionals in for both Clojure (Java) and ClojureScript (Node). I would like to get inspired from others who are testing both... have you any links to existing public repos doing this in a way you think is good?
https://github.com/nedap/speced.def does plenty of reader conditionals in
I find it a sound approach overall, don't recall problems from it.
What is this file for:
I found it confusing to find something outside the
test folder which seems to be related to tests.
That's a minor ns, it provides better IDE integration for Cursive users when using
clojure.test's API is a bit odd about how to extend it (namely with multimethods, which won't play always nicely with IDEs, linters, etc)
See also https://github.com/nedap/speced.def#testing
Take a look at how HoneySQL does this: it's all cljc files and the run-tests.sh file runs both clj and cljs tests.
@U3Y18N0UC not at the moment anyway. I'll cross that bridge when (if) I get there
@U45T93RA6 I can get the tests running, and I see the feedback on STDOUT, but "return value" of
node target/out/tests.js is the same regardless of success or failure. It doesn't play nice with my CI/CD pipeline.
@U04V70XH6 thanks for the pointer to HoneySQL. Sadly for reasons outside things I can change I have to use
lein in the foreseeable future for the project I'm working on.
I don't think that's the case. We've paid close attention to the return value of the Node process If I intentionally break a :cljs reader branch, CircleCI will fail as expected: https://github.com/reducecombine/speced.def/commit/b1f20a3603268bd2e5c2f85e6f9d1ee2bb44647e
The magic sauce being https://github.com/nedap/utils.test/blob/1d4f5a66e89b4703bb8ab227021441946d295373/src/nedap/utils/test/api.cljc#L32-L42 IIRC many codebases implement their own flavor of this - you're right that the unix return code is a gotcha, but not an insurmountable one
I was looking at this:
I must admit I expected less DIY and more "plug this and it works". I guess
lein test set my expectations a bit to high when it came to ClojureScript 😄
lein test generally hasn't worked well for me for running two targets at once (jvm + node). it's seems 'complected' to me, which is why it's explicitly disabled in project.clj
lein test works in my opinion VERY well for Clojure (JVM) only. No hairy setup or knowledge about "test runners" is necessary - it just works as expected. A combined Clojure and ClojureScrip (JVM + node) is an entirely different story - sadly.
The JVM-only experience had set my expectations very high for a combined project. Expectations that obviously was not met 😅
@USW6URK47 Are you using CLJS with Shadow-CLJS? If so, there's a target called :node-tests that do what you want. If you don't, or can't, use it theres another option like re-defining the summary to exist on the right exit code 😄
An example on how I did in a project: https://github.com/mauricioszabo/duck-repled/blob/master/test/duck_repled/tests.cljs#L33-L41