anyone here currently using figwheel-main with cider?

I'm currently getting 'Eval timed out' exceptions whenever I try to use a REPL

i just cranked up https://github.com/pesterhazy/cljs-spa-example with CIDER and i was able to get everything going. do you want to chat in #cider

After doing the obvious thing and updating everything, it seems to be working consistently again 🤞. Thank you though!

I’d love some folks to kick the tires on the new testing support in 0.1.9-SNAPSHOT https://figwheel.org/docs/testing.html

along with the asynchronous main script support

https://figwheel.org/docs/main_script.html

I’ve been building toward providing an effortless testing setup in figwheel for years, I think that these features deliver a lot of value but I’d love some feedback

will give it a try today

Ok so trying to run -main fn as a cli entry point on my project, running

clj -m figwheel.main -co dev.cljs.edn -m playground.test-runner

2018-09-03 16:00:01.740:INFO::main: Logging initialized @26937ms

If I specify an invalid namespace like playground.test-runner111, it correctly reports an error

But if the ns exists but has no fn called -main, there's no error message

Does this boot up a browser in the background, or node?

This boots up a browser by default

I guess that's the part that's not working then

well you need a -main fn

I did try that first of course, with the same result

so nothing happens and no browser launches

correct (I have two Chromes running already, but nothing happens in those either)

that is very odd

and your example is minimal?

Just tried with browsers closed, nothing happens either

I'll try to repro in cljs-spa-example, which is pretty minimal

that would be helpful

Branch here: https://github.com/pesterhazy/cljs-spa-example/pull/12

Same problem:

cljs-spa-example$ clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner
[Figwheel] Validating figwheel-main.edn
[Figwheel] figwheel-main.edn is valid \(ツ)/
[Figwheel] Compiling build dev to "target/public/compiled/app.js"
[Figwheel] Successfully compiled build dev to "target/public/compiled/app.js" in 2.615 seconds.
2018-09-03 16:10:06.345:INFO::main: Logging initialized @10295ms

that is wild

do you have :open-url false?

dude!!

I do indeed

you have :open-url false

I did not make that connection 🙂

sooorry

no worries its an important note

seriously though it wasn't obvious to me that those two were connected

yeah thats how the env get’s started

I know that it seems like :open-url is only related to the --build option

but I think this will all was out in the end because you are going to be using :launch-js to run your tests in headless chrome

I perhaps should warn users that they have chosen to not automatically launch a JS env

and thanks for looking at this, this is very helpful

Now I'm trying the run-tests-async macro

I get

Use of undeclared Var figwheel.main.testing/empty-env

code here: https://github.com/pesterhazy/cljs-spa-example/pull/12/files#diff-a30797170b0a335f6378cbd6cfe34a43

oh dang well thats easy to fix

that’s a path less travelled thanks for finding it

@pesterhazy if you add cljs-test-display back it should work

@pesterhazy I just deployed a fix for that

dang I never tested it with just one namespace

ok cool, just added cljs-test-display back in, now I get test results

this is what it looks like ^^

it tells me that 2 test failed (good!) but not which of them failed

yeah its just using the cljs.test test report

its just cljs test

you should be able to just run (run-tests-async 5000)

and it should find your tests

cljs.test test report prints to the console which tests are failing and why - I guess cljs-test-display overrides that

with the latest SNAPSHOT, I removed the cljs-test-display again, now I get better output:

Testing cljs-spa.core-test

FAIL in (arithmetic-test-expected-to-fail) (at http:433:14)
hello
expected: (= 3 (+ 1 5))
  actual: (not (= 3 6))

FAIL in (async-test-exepcted-to-fail-with-timeout) (:)
Promise rejected: Promise failed to resolve in 50ms
expected: false
  actual: false

Ran 2 tests containing 2 assertions.
2 failures, 0 errors.
#error {:message "ClojureScript async test run failed", :data {:type :end-run-tests, :fail 2, :error 0, :pass 0, :test 2}}

ah that makes sense

might be worth considering reporting to the console as well in cljs-test-display

and does it work with (run-tests-async 5000)

@pesterhazy yeah thats something to think about

after the main output I still get a long, basically irrelevant Java stacktrace - it would be cool to hide that for this specific use case

I thought long and hard about that

and the problem is that if I hide it you can’t compose over figwheel.main/-main

with just (run-tests-async 5000) all I get is

2018-09-03 16:35:18.642:INFO::main: Logging initialized @8205ms
Opening URL 

Testing cljs-spa.test-runner

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
:figwheel.main.testing/success

it is supposed to be top level entry point

@pesterhazy try cleaning and see if you get the same result

I assume you're using the exception to signal failure (status code not= 0) to the top level?

yes

If I System.exit its not very friendly

I could have a top level -main that uses a main that composes

or that plays well as a library function

the output looks way better if I System.exit

its cool that it worked with your promise tests

Yeah if you clean it should detect the tests

which of course is kind of a problem

hmm... if I run

rm -rf target target-prod dist && clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner

(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136

and so on

first error is

(index):126 GET  404 (Not Found)

sounds racey

if you just do one and then the other does that happen?

same thing if I reload the browser

that doesn’t make any sense

I wonder what’s happening

but if I restart clj - without removing target/ etc - it works

but if you remove dist

you need to rebundle right?

and target prod has nothing to do with this current build

what if you just remove target/public?

good points, let me try again

ok pushed a change, the scripts scripts/tests accepts a flag --reset now

scripts/tests --reset

[Figwheel] Validating figwheel-main.edn
[Figwheel] figwheel-main.edn is valid \(ツ)/
[Figwheel] Compiling build dev to "target/public/compiled/app.js"
[Figwheel] Successfully compiled build dev to "target/public/compiled/app.js" in 6.484 seconds.
2018-09-03 16:53:26.402:INFO::main: Logging initialized @13612ms
Opening URL 

and then hangs

in the console,

Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
(index):136 ClojureScript could not load :main, did you forget to specify :asset-path?
(anonymous) @ (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136

doesn’t make much sense to me

its like the asset path isn’t set correctly

oh that’s only caused when the bundle is removed

hmmm but the bundle is regenerated

still sounds racey

the compiler copies the bundle to your output directory

if its not there when you start the compile or hasn’t finished flushing that could be a problem

do you really need to generate the bundle every time you run tests?

or am I missing something? you are hashing the bundle or something?

OK I’m somewhat suspect of this as a minimal example, but I’m grateful that we are able to see these behaviors, at the same time I think this particular behavior isn’t related to the code that runs -main.

failing to detect the tests is a problem that happens when there is only a partial anaylsis of source files

I recreate doublebundle.js on every run, but it's a no-op if the bundle exists and it's up to date, so I think the problem is not related to that

the file that 404s is cljs_deps.js, so I'm wondering why that doesn't exist

sounds like either a race condition

in fact target/public/cljs-out/dev/goog/deps.js - the file that 404s in the browser .- exists

exactly

is it possible that target/ is not on the classpath?

this is a very strange interaction

that seems like it only happens when you mess with the bundle

I notice that I don't see the orange "adding target/ to classpath" message that used to pop up after cleaning

why would messing with doublebundle.js cause goog/deps.js not to be found the first time you run it?

no idea

OK that’s it

just tried it, if I remove the foreign-libs stanza from deps.cljs.edn, I get the same problem, so I don't think it's related to doublebundle.js at all

I don’t think target is getting added when you use main!!

and there is the problem

good catch!

thanks man!!

no, thank you! 🙂

but how did it work the other times?

the second time around, target/ is already there on startup, and it's in :paths in deps.edn

second time around?

I mean if I Control-C clj and restart it, it works again

oh gotcha

because then the target directory is already there and gets added to the classpath by clj

but the first time the target has to be created

before its added to the classpath

... which is too late for it to be noticed by clj

ok

let me fix this

such good stuff

🍺

to confirm our hypothesis this fixes the bug

diff --git a/scripts/tests b/scripts/tests
index 97bd0d9..13d3401 100755
--- a/scripts/tests
+++ b/scripts/tests
@@ -1,10 +1,12 @@
 #!/usr/bin/env bash
 set -euo pipefail && cd "$(dirname "${BASH_SOURCE[0]}")/.."

 if [[ "${1-}" == "--reset" ]]; then
     rm -rf target doublebundle/dist
 fi

 doublebundle/scripts/rebuild-double-bundle

+mkdir -p target
+
 clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner

still doesn't auto-discover the tests though :thinking_face:

Opening URL 

Testing cljs-spa.test-runner

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
:figwheel.main.testing/success

is the tests directory on your classpath?

are the tests on your classpath?

yes, in :paths and :watch-dirs

yeah of course they are

well there is probably a bug there somewhere as well

(run-tests-async 10000 'cljs-spa.core-test) works but (run-tests-async 10000) doesn't (no other changes)

I may have to give up on auto-detection if it doesn’t pan out

personally I think specifying the nss manually it totally fine

it's what we do with doo etc. as well

but of course it would be nicer if auto-detection worked reliably!

Did you try to use headless chrome yet?

Trying that now

https://github.com/GoogleChrome/chrome-launcher looks pretty nice

yeah I’m trying to get away from using node to launch chrome for simple test runs

for complex web driver like interactions it makes a lot of sense

true

but the cool thing is with :launch-js you should be able to do all kinds of stuff like that

start a web server and any other processes you need and then run a web-driver test suite of some kind

Going with this tiny script for now: https://github.com/pesterhazy/cljs-spa-example/pull/12/files#diff-e21770a929afa3b053613ede85b25265

Save for test autodetection, the auto-runner works really well

Headless or headful

@pesterhazy just deployed the target directory fix

One thing that's missing for my use case is that ideally the test runner output would include the script's console output, so you can debug unexpected problems. Karma/doo gives you that

will try the target dir fix tomorrow

thanks for fixing things so fast!

Thanks for testing things out, I’m trying to get this out the door soon.

I’d also like to get your feedback on the :auto-testing if you have time.

I’m going to look at messaging when nothing is configured to start a JavaScript environment.

will give it a spin tomorrow

I'm not sure how you're talking to Chrome so I don't know how much work it would be to implement sending console output, stacktraces etc. back to the test runner process

Yeah I’m guess I’m thinking of using the full fledged environment when debugging tests, and the single run as a canary that’s used for CI and before deployment etc

cause you really want an interactive flow when you are trying to sort something out

you don’t want to be running a single test run over and over when you are sorting out a problem

@pesterhazy thanks for the help

deployed a fix for the messaging when no js env is being launched

@pesterhazy fixed and deployed test namespace auto-detection