Fork me on GitHub

I am using a (start-node {}) to create in-memory nodes for testing, but I noticed that writes are not sync operations ans this makes writing setup scenarios a little harder. There are recommendations on how to turn the writes sync or more general setups for unit tests?


you can do (crux/await-tx node (crux/submit-tx ..))

🙏 6
Steven Deobald01:04:39

@UBSREKQ5Q We have a "Testing How-To" doc pending. What sort of advice would be most useful for you beyond await-tx on an in-memory node?


Thanks @U797MAJ8M. The usage of await-tx means that I will need to include specific code to my functions writing to crux to behave different in test? Would be nice if I could pass a node that had "await-tx" true built in hehe


@U01AVNG2XNF being able to setup an in-memory db has great fit with unit testing using dependency management libraries like Component, Integrant and others


can't think about anything else that does not depend on specific app code to ease testing


what I meant in my first comment was something like this:

(defrecord CruxTesting []
  (start [this]
    (assoc this :tempo/node (with-meta (crux/start-node {}) {:testing true})))
  (stop [this]
    (.close (:tempo/node this))
    (dissoc this :tempo/node)))

(defn save
  [crux-node contract]
  (let [res (crux/submit-tx crux-node [[:crux.tx/put contract]])]
    (if (:testing (meta crux-node))
      (crux/await-tx crux-node res)


you could also use speculative transactions, I think those would get you the new db instantly:


but I think this case is even worst when we think about changes in code base to support tests. The best scenario would be to not change anything and provide an empty db. The function save above should not know that I am testing or not


no big deal to use something like the meta above, curious to know how people deal with this


well, if you want submit-tx to always block you could extend the CruxNode record itself, changing the protocol that controls submit-tx and use that for testing? although I'm not sure what kind of tests you're writing, to me it seems like you could just block in the test code without changing the semantics of application logic


yes, current tests are calling endpoints and checking expected payload responses. not able to block the submit in there 😕

Darin Douglass10:04:37

You could make a fixture that redefs your save fn:

(defn serial-save-fixture
  (let [og-save save]
    (with-redefs [save (fn [& args] (crux/await-tx (apply og-save args)))]
(Sorry for any typos, typing clojure on a phone is difficult)