I tend to do it like this:

(def global-state (atom ...))

(defn handler [{:keys [state]
                :or {state global-state}}]
  ...)

the idea being, I can test handler isolatedly, passing an atom as an arg. Same for each handler - I test them individually, without having to set up something more elaborate. with-redefs is not exactly clean (for one thing it's not thread-safe, if you were to run tests in parallel)

@U45T93RA6 - thanks, injection was the other option

The broader question is, mock function or mock state?

Personally I tend to do both. For example a test-only protocol implementation ("mock function") could write to an atom ("mock data") At the same time I consider mocking some sort of last resource - the idea being to favor hitting pure functions instead

agreed. Though, when one tests a stateful application it is almost impossible to avoid either setting state up or mocking some function

There’s a certain class of bugs that are entirely based on how state is setup and with Clojure, it seems a lot easier to test state than it is in other systems where state is spread across objects or other such systems

an alternative (or at least addition) that comes to mind is doing heavy validation of state in all relevant/possible places e.g. for an atom, use :validator or place :pre in defns asserting that the received state is valid and consistent of course most web apps aren't atom-based, but it's a trick I occasionally use This way, one doesn't necessarily write state-related tests, but instead writes higher-level tests (a user story) and relies in the preconditions being exercised

Yeah, I was just discussing this with someone and we arrived upon spec + state based tests being a pretty solid guard

regarding mocks / with-redefs, the more reliable option is to make update functions that simply take a map and return a map, you test them by offering a map and inquiring about the map that comes back

then, in the actual app, you can use that function as an arg to swap! , but there's no need to attach the state update to the state management code

@U051SS2EU - fair, but how would you test the fn that’s calling swap! ?

by giving it different (limited and testable) functions to call, or limit tests of that function to full integration tests

I would consider it a code smell if the swap! call is nested deep - I expect global effects and mutation to happen at the top of the stack if it needs to happen

(aside from debugging etc.)

Yeah, all the swap! calls here are only in the handlers of a server

The general popular option to test db integrations etc tends to be to pull out a protocol and test it with something reified

with app state, as you say, unit test the individual fns that work on the fragments of the global object and then write integration tests on the swap!/reset! calls to it

yeah, so if your api is atom + fn + swap! your "reified object" is just a simple function

or going the other way, for testing an individual handler, the "test harness" is just a data literal

currently I grab the expected and actual vals by hand and paste them against a diff invocation that I have as an IDE snippet Not too cumbersome, but of course a built-in integration would be nicer

Kaocha probably uses that...

Yeah I can dive into it :) but other than that I tend to be careful around the idea of depending completely in an alternative runner. Same for eftest. Both projects rock tbh, but tests are too important for me to make a migration without some prior study

One way:

user=> (def v1 [:a "A" :b  "B"])
#'user/v1
user=> (apply hash-map v1)
{:b "B", :a "A"}

nice! Thanks

Something with partition?

That something is (partition 2 coll)?

apply hash-map I'd say is what I've seen most often