This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-04
Channels
- # adventofcode (100)
- # announcements (7)
- # architecture (1)
- # aws (14)
- # beginners (209)
- # calva (30)
- # cider (5)
- # cljdoc (2)
- # cljs-dev (37)
- # cljsrn (2)
- # clojure (133)
- # clojure-dev (20)
- # clojure-finland (1)
- # clojure-italy (10)
- # clojure-nl (19)
- # clojure-spec (56)
- # clojure-uk (49)
- # clojurescript (57)
- # clojurex (8)
- # core-async (2)
- # core-logic (1)
- # cursive (38)
- # data-science (19)
- # datomic (28)
- # devcards (3)
- # duct (8)
- # emacs (28)
- # figwheel (1)
- # figwheel-main (31)
- # fulcro (2)
- # jobs (1)
- # kaocha (1)
- # klipse (2)
- # mount (6)
- # nrepl (43)
- # off-topic (20)
- # pathom (3)
- # pedestal (1)
- # re-frame (15)
- # ring-swagger (1)
- # shadow-cljs (47)
- # spacemacs (19)
- # sql (20)
- # tools-deps (58)
- # unrepl (13)
- # vim (5)
Any jdbc-compatible in-memory databases out there? I was going to mock the Connection object in clojure for testing, but the amount of reifying was getting out of control.
Yes, several are tested against as part of clojure.java.jdbc
development.
H2 can do in memory, for example.
{:dbtype "h2:mem" ...}
as I recall -- I'd have to go check the code / tests to be certain...
See dependencies here that java.jdbc
is tested against https://github.com/clojure/java.jdbc/blob/master/deps.edn
H2 is one of them
HSQLDB and Derby aren't "in-memory" but they are JVM-based and use local files so they might be suitable for testing against. Similarly SQLite. But the SQL dialect and column types each different DB supports will all be slightly different.
You might also want to consider just wrapping tests in rollback transactions so you don't need to mock anything, but your tests' changes will automatically undo themselves.
(and then of course there's always the advice to separate actual DB updates from data transformation as much as possible so you can test the transformations without even caring about a database)
Hope some of that is helpful @pablore?
Not sure if java.jdbc
has support for that with Derby. Feel free to create a JIRA ticket. But H2 in-memory is def. supported.
Thanks @seancorfield! Rollback DBs are more difficult to setup on CI and the application I’m developing only reads the database and never wrties to it
derby's in memory database seems to work fine (at least when passing a url as the connection spec)
these days people can also just spin up their actual database in a docker relatively quickly
at my company that's the default solution for running db test suites in our buildserver
just spinning up an empty postgres with a predefined username, throwing the schema and perhaps some initial data in, running the tests, throwing everything away after. works pretty well and we can easily have different versions of postgres around (and also test against new versions) rather easily.