Re: [Caml-list] Unit testing Core Async

[Francois Berenger <francois.berenger@inria.fr>]

There is a google group for Janestreet Core:

https://groups.google.com/forum/#!forum/ocaml-core

You might get more luck in there and some Async specialists.

On 06/15/2015 06:33 PM, Kenneth Adam Miller wrote:
> I've noticed that Core Async requites that a Scheduler.go () call be
> placed-but that never returns. I have a Tcp.server that I'm creating,
> and I like to use oUnit for my tests. Monads and all are beautiful, and
> Core is a wonderful library, but I'm adamant that I have at least some
> minimal functionality testing complete that demonstrates proper behavior
> as well as intended usage.
>
> What I'm wondering is the following: would there be a way to have the
> scheduler.go call be placed in order to fire things off, but in another
> thread have all the test code be dependent on the server's responses and
> all of that, so that once completed, it can call Shutdown.shutdown?
>
> I tried this out, and it introduced some issues.
>
> First, I think that my shutdown call got executed before the unit test
> was able to complete. This is because using Async's Deferred introduces
> some complication if you want behavior to proceed sequentially as in
> without building deeply nested callback chains. What I'm used to is
> asynchronous send, and blocking receive that operates on a common
> execution chain. I don't see any kind of Deferred.await that blocks
> until the instance resolves (yes, there's upon, but that's just nesting
> again because it returns another deferred.
>
> Second, I think shutdown shuts *everything* down. What I need is just to
> signal the completion of the job that was supposed to run, so that the
> Scheduler.go returns in order to allow my unit tests to run to completion.
>
> Third, I'm not certain about the semantics of Pipe/Reader/Writer. It's
> not behaviorally like what I'm familiar with. For instance, callbacks
> may return prematurely and only have part of a message. In ZMQ, what you
> send is what you get. So that makes me concerned in regards to the
> Tcp.Server, because right now what I need is for the Pipe to just allow
> blocking receive so that I can make the threads coordinated, but I need
> the Tcp Server to allow me to receive whole protobuf messages.
>
> Can anyone please help me?

-- 
Regards,
Francois.
"When in doubt, use more types"