Does anyone else run into this error after upgrading to the newest shadow-cljs?

Ahh guess I need the newest core.async

Nvm fixed by upgrading core.async

@mitchelkuijpers oops, yeah upgraded a bit prematurely I guess. I really need to sort out those dep conflicts properly 😛

it seems related that I have a nrepl open for that build

Nope I made a boo boo in my code, but it seems to give errors like this when I screw up a macro

hmm good to know, I’ll check it out

And I have one more question, does shadow-cljs reloads all affected namespaces by default? Or can I turn that on somehow

I have one ns that requires all tests files and I have to touch that before it reloads

all directly affected namespaces, so only namespaces that have a require for the one that was changed

Ah ok maybe I am doing something wrong then

I have a xxxx-test -> tests-to-run -> client-test-main

do you run all the tests all the time?

We have a web renderer for the tests which probably just re-runs all tests or only the changed

I think it only runs changed ones

Maybe i just configured something wrong

test is a somewhat special case since the test runner is constructed by a macro

so technically it depends on all other namespaces but that is not properly expressed anyways

Now it seems to work somehow, not sure what the deal is

For us it is because we have one NS like this:

(ns atlas-crm.tests-to-run
  (:require
   atlas-crm.sample-spec
   atlas-crm.ui.impl.routing.path-spec
   atlas-crm.ui.impl.routing.linear-search-router-spec))

And then this:

(ns atlas-crm.client-test-main
  (:require atlas-crm.tests-to-run
            [fulcro-spec.selectors :as sel]
            [fulcro-spec.suite :as suite]))

(suite/def-test-suite client-tests {:ns-regex #"atlas-crm\..*-spec"}
  {:default   #{::sel/none :focused}
   :available #{:focused :should-fail}})

hmm yes maybe this macro breaks it

yeah because of the indirection or tests-to-run, atlas-crm.client-test-main is not reloaded

since it does not directly depend on the file

I can add a “reload all” but in the past that was total overkill

But it does not matter that client-test-main depends on tests-to-run?

tests-to-run is probably reloaded, but def-test-suite macro probably inspects some analyzer data and is not reloaded to do that again

Aahh ok

Well it works good enough so not such a big deal

why the indirection? why not put all the requires into the client-test-main?

because I also have on for CI

this way I can share them all

(ns atlas-crm.CI-runner
  (:require
   atlas-crm.tests-to-run
   [doo.runner :refer-macros [doo-all-tests]]))

;; This file is for running JS tests via karma/node for CI server
(doo-all-tests #".*-spec")

ah ok

And figwheel does handle this case I think

thats why I want to do a proper shadow-cljs test so you don’t have to write any of that

But if there is better way them I am all ears

Yeah that would be great

which turns green when all tests pass

But I rather have a good console runner with watch

what I could probably do very easily is let you define the test runner

and then use a regexp of some sort to construct the tests-to-run, or rather ensure that the namespaces are compiled/loaded properly

coming up with a new test runner is a lot more work though

Yeah maybe a bit too much work

I think most also allow you to give the namespaces instead of a regex macro thingy

hmm doo is lein specific it seems 😞

The code I have sent I just compile with shadow and then run with karma

this:

(ns atlas-crm.CI-runner
  (:require
   atlas-crm.tests-to-run
   [doo.runner :refer-macros [doo-all-tests]]))

;; This file is for running JS tests via karma/node for CI server
(doo-all-tests #".*-spec")

how do you compile? I have never used karma, what does the config look like? and the build config?

Hold on I will share it

I have a karma.conf file in the root of the project with this in it:

module.exports = function(config) {
  config.set({
    browsers: ['ChromeHeadless'],
    basePath: 'resources/public/',
    files: ['js/ci/ci.js', {pattern: 'js/ci/cljs-runtime/**', included: false}],
    frameworks: ['cljs-test'],
    plugins: ['karma-cljs-test', 'karma-chrome-launcher'],
    colors: true,
    logLevel: config.LOG_INFO,
    client: {args: ["doo.runner.run_BANG_"],
    singleRun: true}
  })
};

I added these deps:

"karma": "^1.7.1",
    "karma-chrome-launcher": "2.2.0",
    "karma-cljs-test": "^0.1.0"

and then I do yarn exec karma start or if you are using npm npx karma start

I have a config in my shadow-build.end like this:

:ci {:target :browser
               :asset-path "/base/js/ci"
               :modules {:ci {:entries [atlas-crm.CI-runner]}}
               :output-dir "resources/public/js/ci/"
               :devtools {:preloads [devtools.preload]}}

with the above pasted CI-runner

I will make a example later this week for fulcro users

excellent. thx. I can definitely remove some of the boilerplate

I see a that a lot fulcro users want to use npm deps but they are not quite sure how, hopefully a example will help

ChromeHeadless is gold btw for CI

(suite/def-test-suite client-tests {:ns-regex #"atlas-crm\..*-spec"}
  {:default   #{::sel/none :focused}
   :available #{:focused :should-fail}})

that has a separate config I presume?

the fulcro tests?

No more cryptic phantomjs errors but sourcemapped errors in the console

That is only to run the tests in the browsers

With that you get the whole testing UI in the browser

The config for that is:

:test {:target :browser
                 :asset-path "/js/test"
                 :modules {:common {:entries []}
                           :devcards {:entries [atlas-crm.cards] :depends-on #{:common}}
                           :test {:entries [atlas-crm.client-test-main] :depends-on #{:common}}}
                 :output-dir "resources/public/js/test/"
                 :compiler-options {:devcards true}
                 :devtools {:http-port 8600
                            :http-root "public" ;; We don't use this but our handler, but this makes shadow start a http server
                            :http-handler dev.test-handler/handler
                            :after-load atlas-crm.client-test-main/client-tests
                            :preloads [shadow.cljs.devtools.client.hud devtools.preload]}}

I have one build for devcards and tests

thx, that helps a lot.

interesting that you’d use a custom handler without static files

I would not have expected that someone would do that 🙂

I’ll mess around with the testing stuff later, already have some ideas.

bbl

Oh do you want the handler I needed it because some assets get server from the classpath