@josephson.victor what I usually do is use two env vars - one for tests, and one for production/dev code.
@mauricio.szabo do you then have to modify your source code to point to the right env var each time you switch between running tests or running a local/dev environment?
Not really, you just have to inject dependencies. For example, instead of defining a "global db pool" you can create a "generate-pool" function that will receive the arguments and return a db pool.
In your main app, you just use (let [db-conn (generate-pool <db-env>)] (start-the-app! db-conn))
And in your test file, you do the (let [db-conn (generate-pool <test-db-env>)] (start-the-app! db-conn))
great, thanks for those suggestions:) For my current code base it was easiest to use jvm-opts in my :test alias per @seancorfield’s suggestion, but I’ll play around with your solution too. Always good to learn multiple ways of doing things
ℹ️ If anyone is running tests with/on GitHub Actions, FYI, GitHub’s https://github.com/actions/setup-java#caching-packages-dependencies “action” https://github.blog/changelog/2021-08-30-github-actions-setup-java-now-supports-dependency-caching/ dependency caching via Maven. This might work for Clojure projects — at least, I hope it will, even if it requires a little tinkering.