Welcome! Please see the About page for a little more info on how this works.

+1 vote
in ClojureScript by
edited by

Using

[cljs.test :refer-macros [deftest is testing run-tests async]] [cljs.core.async :refer [<! go]]

I write async tests like this:

(deftest some-test
  (async done
    (go
      (testing "Sanity check" (is (= 1 1)))         
              .                 
              .                               -> n tests
              .           
      (testing "Sanity check" (is (= 1 1)))     
      (done))))

Up to n=21 tests this works fine, on more I get an incomprehensible thousands of lines error from cljs.analyzer. Is there something I'm doing wrong in how I write these tests?

2 Answers

+2 votes
by

Hello Ladislav

This issue isn't direct related to cljs or test.check

it's related to the go macro

The go macro will rewrite it's body

You can take a look on it by running (macroexpand '(go 1)) in your repl.
Even a simple form, like 1, will turn into a larger form, with a lot of "state machines" and other stuff.
1 results in a ~2k characters long form
Something a bit more complex, like (go (inc (<! (go 1)))), goes to ~4k chars
And it keep growing.

In some cases, this "expanded go code" grows to much, resulting in a StackOverflow or same other wired analyzer error

In your case, the testing / is macro will expand into a large code, so you will quickly have an "too long" form.

by
I see, thanks. I've read basics on go blocks and best practices (https://clojure.org/guides/core_async_go ), but didn't go into implementation details.
+1 vote
by

We need more information in this report. This example actually combines a few different features so it doesn't really feel minimal.

For example does a deftest with 21 testing blocks produce the same problem - i.e. no async, no go etc.

Also we need to see the analyzer errors even if it's the first few dozen lines. Thanks!

by
Thanks for replying. I created a minimal example project: https://github.com/ladislavdubravsky/cljs-test-issue

Both async and go need to be present. The error I get in this minimal example is actually different:
`Execution error (StackOverflowError) at java.net.URLStreamHandler/parseURL (URLStreamHandler.java:312).`
...