test-check

2017-01-10T13:06:17.000140Z

@nberger do you know whether your refactoring of the quick-check function would make it easier to support asynchronous tests?

2017-01-10T13:06:22.000141Z

apologies if I've asked that before

nberger 2017-01-10T15:58:25.000142Z

@gfredericks: I'm not sure what's the issue with asynchronous tests, do you have more context? An example or something to read?

nberger 2017-01-10T15:59:28.000143Z

I do think it should help with running tests in parallel, maybe with a bit more refactoring

2017-01-10T16:25:55.000144Z

@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

2017-01-10T16:26:48.000145Z

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

2017-01-10T16:27:41.000146Z

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

2017-01-10T16:28:22.000147Z

but unless you're already programming with this kind of thing in mind it's usually a big pain to rework the program

2017-01-10T16:28:31.000148Z

so test.check just doesn't support that kind of test at the moment

nberger 2017-01-10T16:34:34.000149Z

@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

2017-01-10T16:35:09.000150Z

no

2017-01-10T16:39:30.000151Z

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

nberger 2017-01-10T17:05:46.000152Z

I see. I didn't take it that far

nberger 2017-01-10T17:43:34.000153Z

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

2017-01-10T18:47:19.000155Z

that would surprise me

nberger 2017-01-10T19:15:27.000156Z

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