This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-10
Channels
- # beginners (97)
- # boot (77)
- # cider (7)
- # cljs-dev (47)
- # cljsrn (3)
- # clojure (125)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (91)
- # clojure-spec (80)
- # clojure-uk (54)
- # clojurescript (92)
- # core-async (6)
- # cursive (17)
- # datomic (56)
- # hoplon (7)
- # immutant (3)
- # liberator (3)
- # luminus (4)
- # off-topic (26)
- # om (41)
- # om-next (11)
- # pedestal (3)
- # perun (3)
- # protorepl (25)
- # re-frame (32)
- # reagent (33)
- # ring (46)
- # rum (3)
- # spacemacs (5)
- # specter (82)
- # test-check (16)
- # untangled (8)
- # yada (26)
@nberger do you know whether your refactoring of the quick-check function would make it easier to support asynchronous tests?
apologies if I've asked that before
@gfredericks: I'm not sure what's the issue with asynchronous tests, do you have more context? An example or something to read?
I do think it should help with running tests in parallel, maybe with a bit more refactoring
@nberger basic use case is wanting to test browser stuff in cljs; if you need to pause the thread to let the browser render things, you can't have a test that just returns pass/fail
you could e.g. return a future or a channel; but that means the quickcheck loop cannot just examine the result, it has to also pause somehow or another until the result is available; traditionally that would mean it would have to shove the rest of the computation into a callback
this is why core.async is so complex, to allow you to pretend your code is synchronous, and the go
macro twists it all into a knot so you don't have to
but unless you're already programming with this kind of thing in mind it's usually a big pain to rework the program
so test.check just doesn't support that kind of test at the moment
@gfredericks: got it. Thought it was something like that but wanted to confirm. Have you seen the async macro in cljs.test? It's definitely not perfect (doesn't play well with with-redefs
for example) but it's a start
I'm asking about your changes because if you tried to take the current code and refactor it to be async, the loop
s would have to be transformed into something more abstract; I wasn't sure if your restructuring had already accomplished that
I'm also not 100% sure in that the loop would have to be transformed. Using an approach similar to the cljs.test async
macro or how some core.async tests are written, which is basically using a "latch" (with countdown or not), the loop can be used as is, even without the refactoring. I'll try to come up with an example next week
that would surprise me