Perhaps this is a bad idea, but I think it would be useful to detect CLJS tests that creates core.async work that is “stuck”. This was my attempt based on help I got in this channel back on March 17, but I can’t get it to work in the case shown in this gist https://gist.github.com/bhb/4bd1897b0f5c761ed9782dae038819dd

I realize this all depends on internals that could change without warning, but since this is just to ensure our tests are sane, i’m willing to endure any upgrade pain and adjust our helpers accordingly if core.async internals chanage

so this won't help get that working, but what I like to do with "blocking" operations in tests is always have a timeout with a failing case. I do that with core.async in clojure, but I am not sure how that would apply to cljs.test

tests that hang when something fails don't make me happy

totally agree with that

the problem we’re having is two fold - first, if we mess up our tests, we miss an assertion that would catch something. you can work around this by carefully writing tests that fail if a block isn’t run, but an automated check would help us catch mistakes. secondly, we’re having issues where running tests in doo for long periods of time will slow down over a series of runs and eventually lock up, so we have to restart our test process.

i’m not sure what’s causing that (i’ve captured profiles in chrome, but they haven’t revealed anything so far) but one thing I’d like to eliminate is the possibility that tests are creating a bunch of blocked core.async work over time and somehow preventing new, legitimate core.async work from running

from my understanding of core.async internals (based on the clojure side of things, so with a huge grain of salt) a blocking task would only stick around if the channel it is blocked on also sticks around

Hm, that could be true. Maybe there really isn’t any blocking work in this case.

@bbrinck we've looked at this a bit with https://github.com/Day8/re-frame-test/blob/master/src/day8/re_frame/test.cljc#L92-L96

but that code is pretty convoluted for what you're trying to do

I know that blocking on timeout channels (which may be a totally different case) is something that can stick around between tests. If you take! on a timeout channel, that callback could be fired during a subsequent test

but timeouts have their own state, at least from my reading of the core.async code, so maybe blocking on a non-timeout channel really does clean itself up

@danielcompton thanks for that!

I should write up a blog post about how CLJS treats async tests

it took me a little while to figure out what was actually going on

and if I don't write it up, I'll need to relearn it in a year 🙂

I’d read that

(love your newsletter, btw)

is there a good reference for async versions of various IO in clojure? I have found aleph for tcp / http, and :callback as an optional arg in zookeeper-clj, but am still looking for good async access to postgres and mongo