This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (4)
- # beginners (53)
- # boot (7)
- # cider (1)
- # clara (1)
- # cljs-dev (13)
- # clojure (29)
- # clojure-dusseldorf (3)
- # clojure-russia (7)
- # clojure-spec (63)
- # clojure-uk (7)
- # clojurescript (51)
- # css (1)
- # datomic (5)
- # emacs (1)
- # events (1)
- # fulcro (15)
- # hoplon (3)
- # immutant (3)
- # juxt (1)
- # midje (2)
- # off-topic (24)
- # om (1)
- # parinfer (1)
- # portkey (54)
- # re-frame (4)
- # reagent (13)
- # schema (1)
- # shadow-cljs (19)
- # sql (1)
- # testing (37)
- # yada (2)
I have a network protocol to implement, which is can be described as a complicated state machine (Petri net, actually). I can easily slap together something, but how do I test it?
I have thought of inverting control, so that every step in a protocol is implemented as a pure function taking current state, event and producing new state and actions to perform (a-la Erlang
gen_server), but then testing it would require crafting this internal state.
if you do the protocol using code in terms of InputStream and OutputStream making test data for tests is straightforward
@noisesmith I'm afraid this is network protocol, not application one. It's a client for layer3 VPN tunnel running over DNS.
if I am testing a pure function, I always have to create the "state" it operates on
@dottedmag right that's fine, what I meant was that it takes bytes as input, and outputs bytes, at some point
That's why I hope there is another way, or a testsuite will be very brittle: any change in implementation would require changing all the tests.
well, it's a protocol, right? if the bytes change meaning you need to change tests...
if you mean implementation as in internal states ... OK you aren't using pure functions
but you should be able to define "reasonable-resting-state" or whatever in the implementing code
They come from somewhere in the production — so maybe the same code should be exposed to the tests to produce the testing state.
and if you express the state right it should be straightforward to express it as a literal in the test via some assoc calls or whatever
E.g. something like
(session-is-now-authenticated state) should be used both by a test which starts from an authenticated state, and by a protocol code itself once the handshake is complete.
also, I have a library for dumping app state (args, return values, whatever) into a document (via transit) and load it as a one liner in my test
(let [app (restore-from-disk "./test/data/overcommit.transit.json"] (is (ok? (recover app))))
All right, I'll start simple (with a handcrafted protocol state), try extracting common code to be used both by implementation and test code and see how it goes.
@dottedmag one thing I do to offset the transit files not being especially human readable is making test assertions where the fact that the assertion passes tells you something about the nature of the thing stored