testing

mauricio.szabo 2021-08-30T15:55:37.000900Z

@josephson.victor what I usually do is use two env vars - one for tests, and one for production/dev code.

valsen 2021-09-01T16:04:42.003300Z

@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?

mauricio.szabo 2021-09-01T16:10:34.003500Z

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))

mauricio.szabo 2021-09-01T16:11:02.003700Z

And in your test file, you do the (let [db-conn (generate-pool <test-db-env>)] (start-the-app! db-conn))

valsen 2021-09-01T18:39:14.004Z

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

avi 2021-08-30T20:50:51.002800Z

ℹ️ 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.