Fork me on GitHub

@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.

Geoffrey Gaillard22:12:25

Fixed with SHA 9d4698b4bdf7e8d7286d52497227fa9670b39ba3

Geoffrey Gaillard18:12:48

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
  . 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.

Geoffrey Gaillard18:12:49

I’ll give it a look

Geoffrey Gaillard22:12:31

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?

Dustin Getz20:12:21

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...

Dustin Getz20:12:07

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 🙂

Dustin Getz20:12:19

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?

Geoffrey Gaillard18:12:27

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.