The not simple way out: lift starting the node from the ns containing XT logic, so I could require it in tests.

yep, you've got it, the node will need to be closed. we usually either go for test fixtures, as you say, or if all the references to the node are within a certain scope, a with-open

in your case, sounds like a :once fixture to start up and tear down the node should do the trick?

(def ^:dynamic *node* nil)

(t/use-fixtures :once
  (fn [f]
    (with-open [node (xt/start-node {})]
      (xt/submit-tx node ...)
      (binding [*node* node]
        (f)))))

Not if I have a foo.xt-logic that does (def node (xt/start-node {})) and then I require it in the test ns.

can the functions in foo.xt-logic take the node as a parameter?

They already do, yep. Just need to lift the node itself somewhere else.

It would be nice to have a workaround, though. E.g. to support using hyperfiddle/rcf tests throughout the ns. (https://clojurians.slack.com/archives/C7Q9GSHFV/p1706818329319899, same issue.) It works fine at the REPL, so maybe that's enough.

It's obviously my poor hygiene at fault, just wondering if there's a workaround.

fair, yep - something like integrant/integrant.repl, perhaps, to manage the lifecycle? :thinking_face:

Only have a server and XTDB, so I'm resisting adding more perhaps unnecessary complexity 🙂

also fair 🙂

Thanks for your time

yw 🙂 🙏

This might be convenient at the REPL (as long as you run the tests manually or through rcf) and it exits properly:

(ns test
  (:require
   [xtdb.api :as xt]
   [clojure.test :refer :all]
   [hyperfiddle.rcf :refer [tests]]))

(def node (xt/start-node {}))
(xt/submit-tx node [[::xt/put {:xt/id 1}]])
(xt/sync node)

(use-fixtures :once
  (fn [t]
    (t)
    (.close node)))

(deftest bar
  (is (= (xt/entity (xt/db node) 1)
         {:xt/id 1})))

(tests
  (xt/entity (xt/db node) 1) := {:xt/id 1})

I'm going to reinforce the "poor hygiene" aspect and note that top-level content in namespaces (`def` and other non-`defn` expressions) should never have any side-effects -- those things happen when you load a namespace, so they'll happen if any tooling loads your namespace to analyze it or if you try to compile the namespace. It really is a good practice to adopt to always put side-effects into functions so you can control when they happen.

Thanks for jumping in, Sean! Spurred on by your comment (James was too gentle 😁), I took the time to clean this up. I also accepted that not all tests can/should be 'inlined'. (This was in turn inspired by some of Sean's arguments I found online.)

> James was too gentle 😁 noted for next time 😈