@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

no

I'm asking about your changes because if you tried to take the current code and refactor it to be async, the loops would have to be transformed into something more abstract; I wasn't sure if your restructuring had already accomplished that

I see. I didn't take it that far

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

Yeah, thinking more about it, a different abstraction would be needed. I'll hopefully have some time to play with it next week