This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-21
Channels
- # beginners (5)
- # boot (15)
- # capetown (1)
- # chestnut (2)
- # cljs-dev (9)
- # cljsjs (3)
- # cljsrn (1)
- # clojure (190)
- # clojure-brasil (2)
- # clojure-greece (14)
- # clojure-italy (3)
- # clojure-poland (8)
- # clojure-romania (1)
- # clojure-russia (2)
- # clojure-serbia (3)
- # clojure-spec (38)
- # clojure-uk (98)
- # clojure-ukraine (2)
- # clojurescript (65)
- # clojurex (1)
- # core-async (16)
- # cursive (16)
- # datomic (3)
- # defnpodcast (7)
- # emacs (11)
- # funcool (2)
- # hoplon (16)
- # jobs (1)
- # leiningen (4)
- # lumo (9)
- # off-topic (2)
- # om (1)
- # other-languages (1)
- # protorepl (1)
- # re-frame (50)
- # reagent (16)
- # reitit (32)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (73)
- # spacemacs (36)
- # specter (21)
- # sql (6)
- # unrepl (107)
- # untangled (4)
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"
I think ultimately what you want for testing that kind of thing is some kind of state machine dsl
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
so I end up with something almost like a regex for describing the messages consumed from a channel
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.
one approach I have used is to have something representing the whole history so far, and another value representing the history of states
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
(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)
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.
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
@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)] ...)
ah... that's a very interesting idea, holding all history to assert that certain messages happened ever, or happened in a particular order.
right, I found it simplified my unit testing a lot