This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-18
Channels
- # adventofcode (20)
- # aleph (25)
- # announcements (4)
- # babashka (117)
- # beginners (150)
- # calva (4)
- # cider (9)
- # clj-on-windows (2)
- # clojure (9)
- # clojure-europe (4)
- # clojure-italy (3)
- # clojuredesign-podcast (18)
- # clojurescript (16)
- # conjure (1)
- # core-async (35)
- # cursive (13)
- # datalevin (6)
- # datomic (6)
- # fulcro (8)
- # hyperfiddle (5)
- # malli (8)
- # nextjournal (4)
- # off-topic (51)
- # pathom (4)
- # reagent (21)
- # sci (14)
- # shadow-cljs (22)
- # specter (3)
- # testing (22)
- # tools-deps (8)
- # xtdb (7)
@ggaillard Following on from that thread about RCF, I have a couple of questions...
First off, I see RCF depends on ClojureScript but we have a pure Clojure codebase and do not want to bring ClojureScript in as a dependency. Does RCF work with ClojureScript excluded?
I've actually answered that for myself in a REPL (the answer is "no") so now my question is: could RCF be made to work in a non-ClojureScript environment?
(! 574)-> clj -Sdeps '{:deps {io.github.hyperfiddle/rcf {:git/sha "c399b1b621b19dc576ea46cd4b254477e1ca9756" :exclusions [org.clojure/clojurescript]}}}' -J-Dhyperfiddle.rcf.generate-tests=true
Clojure 1.10.3
user=> (require '[hyperfiddle.rcf :as rcf :refer [tests]])
Syntax error (FileNotFoundException) compiling at (hyperfiddle/rcf.cljc:1:1).
Could not locate cljs/analyzer/api__init.class, cljs/analyzer/api.clj or cljs/analyzer/api.cljc on classpath.
It is definitely possible. There is an open issue for it (#25). It’s just TBD.
ClojureScript brings in this set of dependencies:
org.clojure/clojurescript 1.10.896
. com.google.javascript/closure-compiler-unshaded v20210808
. org.clojure/google-closure-library 0.0-20211011-0726fdeb
. org.clojure/google-closure-library-third-party 0.0-20211011-0726fdeb
. org.clojure/data.json 0.2.6
. org.clojure/tools.reader 1.3.3
. com.cognitect/transit-clj 0.8.309
. com.cognitect/transit-java 0.8.332
. com.fasterxml.jackson.core/jackson-core 2.8.7
. org.msgpack/msgpack 0.6.12
. com.googlecode.json-simple/json-simple 1.1.1
. org.javassist/javassist 3.18.1-GA
. commons-codec/commons-codec 1.10
I guess one option for us would be to have a stub for hyperfiddle.rcf/tests
for "production" use that was just one file with a macro that expanded to nothing, and then live with the ClojureScript dependency in dev/test/CI but that feels like a bit of a hack.I’ll give it a look
With sha 9d4698b4bdf7e8d7286d52497227fa9670b39ba3
$ clj -Sdeps '{:deps {io.github.hyperfiddle/rcf {:git/sha "9d4698b4bdf7e8d7286d52497227fa9670b39ba3" :exclusions [org.clojure/clojurescript]}}}' -J-Dhyperfiddle.rcf.generate-tests=true
user=> (require '[hyperfiddle.rcf :as rcf :refer [tests]])
nil
user=> (rcf/enable!)
true
user=> (tests 1 := 1)
✅.nil
Wow, really? That's awesome... I'm binge-watching Discovery stuff right now but will try that out tomorrow I expect!
I see that -Dhyperfiddle.rcf.generate-tests=true
doesn't really play well with the REPL experience in a few ways. There's a ticket open for the return value but there's a deeper problem too -- one I ran into with Expectations: RCF generates named tests based on the line number in the file. If you're editing code and tests
ends up on different lines when you load the file multiple times (or even just eval the tests
block itself multiple times) then you end up with multiple deftest
definitions in the ns and no good way to remove the outdated ones. I like the idea of generating actual tests but that auto-naming issue is definitely problematic. Any thoughts on that @ggaillard?
Hi sean thanks for the report – the flag is meant for CI, is there a good reason to run with that flag on at dev REPL? Like are you trying to integrate with a clojure.test workflow? We could potentially just improve the readme and warn not to do this
My workflow is editor-based and I regularly run tests via hot keys while I'm developing code -- in addition to evaluating forms directly inside comment
blocks.
So I really like the idea that of being able to run tests
forms via that same interactive testing scenario -- and it almost works...
I see, thanks, that is worth fixing if we can
I wrote my thoughts in the GH issue about it.
Having gone through the whole Expectations thing, it's kind of close to my heart there 🙂
yeah thanks i saw that late
(I never type into a REPL -- I only ever use a REPL as a way to evaluate code from a connected editor -- so I use a mix of load-file and eval block, as well as running tests, which is why I would want tests
to produce deftest
forms during dev and therefore why I would run into this)
It's why I created the clojure.test
-compatible version of Expectations that uses named tests to avoid that problem.
Perhaps a named-tests
variant that always took a symbol as a first argument, and then only turn those into deftest
(and not plain tests
) when some setting is provided?
Nice catch! Generated tests should definitely have a stable identity. A name would do it. We’ll have to think about the essence of it and potential alternatives. Just created an issue to track it. https://github.com/hyperfiddle/rcf/issues/41