This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-16
Channels
- # announcements (1)
- # babashka (23)
- # beginners (157)
- # boot (3)
- # calva (2)
- # chlorine-clover (12)
- # cider (14)
- # clara (5)
- # clj-kondo (6)
- # cljs-dev (61)
- # cljsrn (30)
- # clojure (65)
- # clojure-argentina (8)
- # clojure-berlin (2)
- # clojure-europe (13)
- # clojure-france (9)
- # clojure-germany (2)
- # clojure-italy (4)
- # clojure-nl (6)
- # clojure-portugal (2)
- # clojure-romania (2)
- # clojure-uk (76)
- # clojurescript (56)
- # conjure (52)
- # core-async (37)
- # datomic (209)
- # duct (17)
- # emacs (17)
- # exercism (1)
- # fulcro (26)
- # graalvm (5)
- # instaparse (2)
- # jackdaw (9)
- # jobs-discuss (27)
- # joker (2)
- # juxt (23)
- # leiningen (4)
- # malli (11)
- # midje (3)
- # pedestal (2)
- # quil (2)
- # re-frame (78)
- # reagent (8)
- # reitit (18)
- # remote-jobs (1)
- # ring (2)
- # ring-swagger (1)
- # shadow-cljs (29)
- # sql (11)
- # test-check (12)
- # tools-deps (5)
- # xtdb (16)
- # yada (4)
Hi guys, I’d like to use a different db (duct.database/sql) when running my tests (via: lein test, or the repl : dev> (test) ) vs. the one I use in development and in production. The idea is to have a h2 in memory db (vs a postgres db in dev/prod) where the same migrations would be run (+ some lines inserted for the tests). Is this a good parctice? How would you achieve this ? Is creating a new lein profile the good way ? thx !
You could define a :duct.database.sql/hikaricp
value in your dev.edn
which also included a key initialising your H2 db (`:dev.db/H2` or whatever). You'd need to make sure that the H2 db component initialised first though to make sure that the connection could be made - this could be achieved by just adding a reference to :dev.db/H2
to the hikaricp key.
We actually do something very similar to this except that we have postgres in memory instead of H2. We use this: https://github.com/Bigsy/pg-embedded-clj
I'm not sure how easy it would be to add in extra ragtime migrations in a separate profile though.
Asked a similar question, a boundary (defprotocol) we defined ourselves, but idea is the same I think
So create a test profile I guess with the specific config for test
duct profile
Instead of writing to postgres you write to h2
I think it is a good practice.
You could also setup the environment with a local postgres instance (docker image) and then run integration tests against that.
Then mark the tests with (deftest ^:integration
and add test-selectors to project.clj
:test-selectors {:unit (complement :integration)
:integration :integration}
so you can run unit tests with lein test :unit
and integration tests with lein test :integration
hello @U2PGHFU5U and @UJF10JP8A, thank you very much for your replies that helped me solve my issue. What I did is that : 1. I realized that in [duct/core “0.8.0”] a specific duct.profile/test was introduced (I was using 0.7.0), and upgraded to 0.8.0. This helped me avoid the creation of test lein profile 2. In my config.edn added a line (below the dev profile one) :
there is a small issue that caused me a crash in duct.core and this is why I had to introduce the “.edn” extension (https://github.com/duct-framework/core/issues/23)
and then : 3. added in duct_hierarchy.edn the code:
{:my-project.migration/h2 [:my-project.migration/sql]
:my-project.migration/postgres [:my-project.migration/sql]}
4. referenced :my-project.migration/sql in the config.edn file :
:duct.migrator/ragtime
{:migrations [#ig/ref :co.ytems.aeolus.migration/sql]}
5. defined the :my-project.migration/h2 in test.edn file and :my-project.migration/postgres in both dev.edn and prod profiles