im also curious what specific problem are you facing. we are also using datomic client api, because our production system is Datomic Cloud. for testing we use https://docs.datomic.com/cloud/datomic-local.html#memdb we have some convenience layer around initializing a new databases with their schemas. then a test setup looks something like:

(deftest x-test
  (let [{:keys [datomic/xxx-db]} (fake-svc/mk)]
    ; GIVEN
    (-> [[{:some 'data}]

         [{:some/more 'data}
          [`in/another :transaction]]]
        (->> (run! (partial map dc/tx! xxx-db))))

    (is                                 
      ; THEN
      {:expectation met?}
      ; WHEN
      (-> [(some-tx-generating-fn {:with 'some} "params")]
          (->> (dc/tx! xxx-db))
          ; and
          ; 1. interrogate the :db-after via some datalog query
          ; 2. pull some entity from :db-after based on some temp ID 
          ;    converted to an actual ID via :tempids
          ))))

where dc/tx! is something like:

(defn tx! [conn tx-data] 
  (d/transact conn {:tx-data tx-data}))

alternatively, u can test multiple scenarios, which share a common setup (the GIVEN part), by not transacting within the is, but instead using d/with, like

; WHEN
(-> [(some-tx-generating-fn {:with 'some} "params")]
    (->> (d/with (d/with-db xxx-db)))
    :db-after
    ...
    )

furthermore, it might worth using actual https://docs.datomic.com/cloud/transactions/transaction-functions.html, instead of functions which just return transaction data, because they can be also used in the GIVEN section to setup a realistic database state concisely, like i showed in the [<backtick>in/another :transaction] case above. then the transaction-(data)-under-test would just become

[[`some-tx-fn {:with 'some} "params"]]

of course u can directly unit test some-tx-fn too and assert what tx-data does it generate, but to make sure that the generated tx-data is actually transactable, u want the other kind of tests above, which actually attempt to transact it too.

another trick u might want to utilize is to name your test entities. that simplifies both test setup and the querying of the resulting database value too, because u don't have to deal with numerical entity IDs that much. eg, instead of

; GIVEN
    (-> [[{:our.user/id    (random-uuid)
           :our.user/email ""}]

         [{:some.entity/owner [:our.user/email ""]
           :some.entity/attr  'ibute}]]
        (->> (run! (partial map dc/tx! xxx-db))))

; GIVEN
    (-> [[{:db/ident       :u1
           :our.user/id    (random-uuid)
           :our.user/email (str (gensym "user-") "@gmail.com")}]

         [{:some.entity/owner :u1
           :some.entity/attr  'ibute}]]
        (->> (run! (partial map dc/tx! xxx-db))))

making a new database for every test case takes less than 10 millisec on an Apple M2 Pro machine, so that shouldn't really be your concern.

actually, i just measured it and it took between 14 msec and 6 msec randomly.

in other words 100 test cases would spend ~1s on preparing a new test db

when u r unit testing just transaction functions or queries, then it's also possible to use a transduction to speculatively apply you GIVEN scenario onto a common db, which already has the schema transacted, but that's added complexity. regardless, as a reference, here is an example how would such a function looks like in our system:

(defn with-txs
  "Speculatively apply the `txs` transactions to a `dc|txr|with-db`.
   Transform the last transaction result with `completing-fn`, if specified.

   As its name suggests, `dc|txr|with-db` can be:

   1. `dc` - Datomic component, with a `:branch` key, containing a `d/with-db`
      or an `rmap/rval`, which would valuate to a with-db.

   2. `txr` - A \"transaction result\" map, as returned by `d/with`, allowing
      the chaining of `with-txs` calls.

   3. `with-db` - a with-db, directly."
  ([dc|txr|with-db* txs*] (with-txs dc|txr|with-db* txs* identity))
  ([dc|txr|with-db txs completing-fn]
   (transduce
     (map txm)
     (fn reduce-tx
       ([] {:db-after (or (-> dc|txr|with-db (rmap/get! :branch))
                          (-> dc|txr|with-db :db-after)
                          (-> dc|txr|with-db))})
       ([txr] (completing-fn txr))
       ([txr tx] (-> txr :db-after (d/with tx))))
     txs)))

dc is short for datomic component. it's a concept specific to our system txr is short for transaction result or receipt with-db just means the object returned by d/with-db, which is the same kind of object u get from the :db-after of a d/with call.

so there is some monad lurking in there where the monadic values are {:db-after <with-db>}, but i haven't felt the need to be that abstract about this problem.

Thanks a lot @U06GLTD17 @U086D6TBN! Your responses have been very helpful. I started working with datomic recently and wasn’t sure about how to go about testing: How to set up/Tear down, best practices, etc.

we don't even tear down the dbs tests make temporarily, because we usually restart our REPLs about daily, so there's little chance to accumulate too much db garbage.