Fork me on GitHub
#core-async
<
2017-11-21
>
rwilson21:11:19

Is anybody aware of useful libs for testing core.async systems?

rwilson21:11:45

For things like expecting a particular message on a given channel, respective or irrespective of ordering. I find myself writing a lot of things like, "do something, and then take from a channel until receiving something expected"

hiredman21:11:04

I think ultimately what you want for testing that kind of thing is some kind of state machine dsl

hiredman21:11:22

I've fiddled a little with using https://github.com/ztellman/automat, but ultimately ended up writing a little parser based on parsing with derivatives for it

hiredman21:11:08

so I end up with something almost like a regex for describing the messages consumed from a channel

rwilson22:11:57

Hm... yeah, it gets tricky to manage when there a variety of events produced and the order is nondeterministic. I'm envisioning something to define a set of expectations of messages on a channel, each of which could add new expectations or resolve in a success/failure manner, and the whole system of which would resolve as a success or failure.

noisesmith22:11:17

one approach I have used is to have something representing the whole history so far, and another value representing the history of states

noisesmith22:11:44

then you can test whether the history contains a certain event, or if an event matching condition a happened before an event matching condition b

noisesmith22:11:42

(when I talk about something representing the history so far, and another value representing the history of states, this is specific to an event sourced system, where a reduce derives a “state of the world” out of a series of events)

rwilson22:11:24

That's an interesting idea. The "state of the world" I'm dealing with is similar, with the exception that it mutates over time in the absence of additional input, though you could consider "time" the input in that case.

noisesmith22:11:11

yeah, this is a case where event-sourcing makes things easier because it guarantees a finite number of discrete states which are straightforward to store and query in test code

noisesmith22:11:03

@rwilson also consider that if you can add swap! calls into the system at the right places (this could even be inside an xf on a channel) you can get a history reified into a collection (let [history (atom []) tracking-xf (map (fn [e] (swap! history conj e) e)) in (chan 1 tracking-xf)] ...)

rwilson22:11:58

ah... that's a very interesting idea, holding all history to assert that certain messages happened ever, or happened in a particular order.

noisesmith22:11:17

right, I found it simplified my unit testing a lot

hiredman22:11:10

non-deterministic ordering of events is just a more complicated state machine / parser

hiredman22:11:10

instead of x -> y, you have x -> y or z or w