Clojurians Log v2

Hi, I just setup testing with figwheel, according to the https://figwheel.org/docs/testing.html docs. It's working well for the most part, except that when I add a new deftest, it isn't picked up on recompile. Only the tests that existed on initial compilation are detected. Changes to detected tests are picked up on recompile, but new tests are not. Is this expected, or what might be amiss?

@jyee117 what kind of testing are you doing?

the :auto-testing ?

I'm using :extra-main-files config option, with a test-runner namespace that executes tests using (figwheel.main.testing/run-tests (cljs-test-display.core/init! "app-testing"))

OK and you are adding a new test to an existing namespace and you are saying its not detected?

is it a simple test or is it asynchronous?

like if you add a (deftest new-test (is (= 1 2))) to an existing namespace you are saying it doesn’t get run?

That's correct, adding a simple test like your example isn't run. But the testing namespace has existing tests that are run, and changes to those tests are shown.

I'm also running figwheel via the API. So I start a lein repl and then start figwheel with => (fig), which calls (start {:mode :serve} "dev") (cljs-repl "dev).

@jyee117 OK I took a look at the code

I may have to try an example

@jyee117 what are the figwheel options your are using?

because you need CLJ reloading for new tests to get picked up

oh wait no thats wrong

the main thing is that your runner namespace needs to be recompiled

and reloaded

so the :recompile-dependents cljs option has to be true , which is the default I think

That's probably it, I have :recompile-dependents set to false for better performance. I'll test that out now.

Good news, my work is now compiling CLJS using figwheel.main in dev and cljs.main for production. Been using boot since the inception of the project, but now we're doing hybrid build.

@borkdude fantastic!

that should be a big improvement

@jyee117 the problem is that run-tests relies on macro expansion during compilation to incorporate the new tests

We're using this babashka script to run 3 processes (CLJS, less and CLJ) in one terminal for development: https://gist.github.com/borkdude/8f5dff7c2330ca520403eb44c9013a83 Unfortunately only one REPL gets to interact with stdin in this way. Not sure if it's still possible to get access to the CLJS REPL, maybe via the running process on port 9500?

@borkdude nah it doesn’t work like that

I guessed so, it's rebel readline right?

Anyway, we can also just run the three processes separately. no problem

yeah, but that’s not important, you can skip rebel-readline

its best to connect to the CLJS repl through your editor

anyway

how does one do this? I guessed this should be done using inf-clojure interacting on stdin?

nah

the best way is with nrepl

and piggieback

most editors speak that language

cider for emacs

yeah, I had that in the previous setup, so I'm familiar with it, but too lazy to actually start it. the figwheel REPL just opens itself, which is kinda neat 😉

but you would have to start an nREPL process that includes cider in your figwheel process

I mean includes piggieback and cider

cool you got it

am I right that without the -r option I also don't get reloading?

yep

so the REPL is coupled to the reloading?

you have to have the -r option unless you start figwheel with the api

yes the REPL is the connection

ok, then our config makes sense.

:cljs/dev {:extra-deps
                      {com.bhauman/rebel-readline-cljs {:mvn/version "0.1.4"}
                       com.bhauman/figwheel-main {:mvn/version "0.2.11"}
                     ...
                      :extra-paths ["src-cljs-dev"]
                      :main-opts ["-m" "figwheel.main" "-co" "common.cljs.edn"
                                  "-d" "frontend/public/js/app.out"
                                  "-o frontend/public/js/app.js"
                                  "-c" "<http://dre.app|dre.app>"
                                  "-r"]}

we also use it for CSS reloading

using this for CSS:

:less/dev {:extra-deps
                      {deraen/less4clj {:mvn/version "0.7.4"}}
                      :main-opts ["-m" "less4clj.main"
                                  "--auto"
                                  "--source-map"
                                  "--inline-javascript"
                                  "--source-paths" "resources/public/css" "--target-path" "frontend/public/css"]}

but you don’t need rebel-readline-cljs ?

yeah the less bit is cool

yeah, I guess so, I just copied that from the figwheel docs

yeah you don’t need it

it will start faster without it

I'll remove it then, thanks for the advice.

I saw your tweet where you were dancing with the bird, I think, I freaking loved that

haha, thanks. my twitter account got blocked a week or so ago, because of that video, which contained copyrighted music

@bhauman New tests are indeed picked up on recompile when :recompile-dependentsis set to true. I may have to dig deeper into alternative strategies if that slows things down too much, but I'll probably just toggle it as needed for now. Thanks for the help!

@jyee117 you can run two different builds if it get’s too much

oh crap, well it was worth it for sure

@borkdude So instead of running clj commands manually, you run that dev script using bb to set everything up. Cool approach. Thanks for sharing!

that's right @tkjone

and you get to interact with one of those three via stdin as well

I could enhance that script by prefixing the output from each process with some string like ---- less : or something so the outputs are more distinguishable

@bhauman I'm looking at background builds, which look like a nice way to do this. Thanks for the tip~

quite frankly a seperate test.cljs.edn file works much better and is more predictable