Fork me on GitHub
#core-async
<
2016-02-17
>
genRaiy12:02:08

guys - does anyone have some good resources for testing with core.async?

meow16:02:33

#C08LK2DH7 is a good place to ask as well

dialelo18:02:25

@raymcdermott: in Clojure you can use the blocking version of take (`<!!`) to block for async results, and in CLJS use cljs.test.async for asynchronous tests

genRaiy19:02:17

@meow: thanks I didn’t know about that channel

ghadi19:02:05

specific to core.async -- Pass yo' Channels In, Folks.

ghadi19:02:27

I almost treat them like external dependencies in the same style as Dependency Injection

ghadi19:02:53

That makes testing easier, as you don't care who is suppling a channel, just that you can consume it.

ghadi19:02:12

Don't make assumptions about the other end of a channel

ghadi19:02:29

Channels as arguments to processes.

genRaiy19:02:03

@dialelo: pretty heavyweight abstractions - good though I didn’t know about that library and it looks really interesting

genRaiy19:02:56

@ghadi: even the output channel?

ghadi19:02:29

It depends on your particular needs.

ghadi19:02:34

I'm making generalizations

genRaiy19:02:02

@ghadi: ok fine, it’s all this talk of DI that’s scaring me 😛

ghadi19:02:45

s/DI/pass arguments to functions/ 😛

genRaiy19:02:45

sure, that’s my approach in general anyway … so then you just tap off the inputs and test the channel logic and compare output?

ghadi20:02:58

I don't necessarily use tap. All I mean is, if you have Subsystem T under test, and that it needs some channels as input arguments when it starts -- provide those arguments explicitly in the test. Subsystem T doesn't need to know whether those came from Subsystem A or some mock data on a channel.

ghadi20:02:25

As opposed to: Subsystem T discovering its inputs during initialization

ghadi20:02:40

tldr: don't discover, inject as arguments