There's an "embedded" version of PostgreSQL that next.jdbc is tested against -- instead of a separate instance of PG running standalone, the tests start the embedded version and use that for all the DB tests. See https://github.com/seancorfield/next-jdbc/blob/develop/test/next/jdbc/test_fixtures.clj#L130-L133 for the setup as a datasource but you'll need to look at deps.edn and the top of that test-fixtures namespace for a few more bits of it.

do you recommend the embedded version vs a separate PG running standalone?

With Docker, it's easy to spin up a new instance of PG on demand so that's a possibility too. At work we use Docker for local instances of Elastic Search, Percona, and Redis. I mentioned the embedded PG option because quite a few people suggest using some embedded DB for testing... I use it for the ease of testing but if you're already using Docker, that's probably "better".

It seems pretty easy for me to spin up a PG instance, so that's not an issue I moreso can't find a simple copy and pastable code snippet for setting up and tearing down that second testing db

I guess I'm not sure what you're asking then -- you just point your app at a different database for running tests.

If you have specific data that is needed by tests in a particular namespace, you can use-fixtures (in clojure.test) to setup data, run the test, and tear it down.

yeah I'm mainly just looking for a simple example of use-fixtures that shows how to setup the db and tear it down on demand for the unit tests

Take a look at the test code for next.jdbc

that helped any thoughts on this issue? https://clojurians.slack.com/archives/C053AK3F9/p1657390667098349

There are so many moving parts there... but next.jdbc itself has tests that run things inside a rollback-only transaction and that works. I suspect something inside HugSQL is causing the behavior you are seeing -- but I don't use HugSQL (nor do I use Mount).

This is partly why I recommend beginners don't use Luminus until they've learned more of the basics and can figure out how each piece works on its own.

I had a quick look at HugSQL's code and I don't see anything that would mess with the connection but it's several levels of abstraction and it's not clear to me exactly what processing it is doing on the connection being passed in...