That helps-I was literally looking up a way to running unit tests on that google group. I think that group helped a lot, I'll try and read what I can there before I blast the list (I didn't know about it before hand). On Mon, Jun 15, 2015 at 12:53 PM, Carl Eastlund wrote: > Internally at Jane Street -- and this may show up in some of the publicly > released code, but off the top of my head, I don't know what file to point > you at -- we run some of our async unit tests using > [Thread_safe.block_on_async_exn]. That will spin up the scheduler if > necessary, run the function you give it, block until the deferred is > determined, then return. It does not shut down the async scheduler; we > generally don't do that until the program is done, so we would leave the > scheduler up from one test to another. I don't know the entire rationale > behind this design, there may be a way to shut down the scheduler in > between tests, but in general it does not appear to be necessary. > > As for partial reads, if you're concerned with receiving whole messages, I > think [Reader.read_one_chunk_at_a_time] can do what you need -- if you get > too little, just return [`Consumed (n_already_consumed, `Need > n_total_bytes_to_proceed)]. > > I hope this helps! > > On Mon, Jun 15, 2015 at 12:33 PM, Kenneth Adam Miller < > kennethadammiller@gmail.com> 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? >> > > > > -- > Carl Eastlund >