This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-19
Channels
- # admin-announcements (1)
- # beginners (26)
- # boot (6)
- # cider (14)
- # cljsjs (29)
- # cljsrn (19)
- # clojure (87)
- # clojure-austin (5)
- # clojure-belgium (10)
- # clojure-brasil (2)
- # clojure-dusseldorf (15)
- # clojure-greece (17)
- # clojure-russia (51)
- # clojure-sanfrancisco (4)
- # clojure-sweden (20)
- # clojure-uk (31)
- # clojurescript (111)
- # core-matrix (2)
- # cursive (9)
- # datascript (15)
- # datomic (41)
- # dirac (1)
- # emacs (8)
- # flambo (1)
- # funcool (4)
- # hoplon (72)
- # lein-figwheel (3)
- # off-topic (2)
- # om (79)
- # om-next (2)
- # onyx (17)
- # other-languages (16)
- # re-frame (62)
- # reagent (26)
- # remote-jobs (1)
- # rum (3)
- # spacemacs (5)
- # untangled (120)
ha okay - so I am actually from the Racket community, though have coded in Clojure too. This is more of a high level question: I want to set up my integration tests so that the database cleans up after itself, i.e. after incurring database side-effects, the database will do a rollback. My difficulty is when feature testing with rollbacks - I can transactions working with unit testing. If I make a test request to the server, the server will do database stuff but if I wrap the request to the server in a transaction, the rollback doesn't undo the changes the server makes - presumably because the test and the server are interacting with the database with separate sessions. Has this problem been solved in Clojure?
but at the moment, the testing framework behaves as the client and launches a request, the server then writes to the database - is there a way to wrap each test in a transaction so that it can rollback between tests? I've done this in Ruby using DatabaseCleaner
when we do that, we test on a separate instance of the server that is not connected to the production database
ah ok - so at the functional/feature test level, rolling back your database is less of an issue? Only at unit test level do you do rollbacks?
I always do my testing on a separate db instance, or at least a db instance I don’t mind being wiped out by my tests
I never use transactional rollbacks to revert db state. I see the appeal, but I always control my db transactions explicitly in my app code. Put another way, transactional guarantees are a property of my database interaction which I very much care to specify in my tests.
When and if I get to the point where my database interaction in tests are so pervasive as to become annoying or slow, I’ll look to introducing a protocol with a smaller surface area which I can specifically test in integration with the db, and reify a mock implementation for testing with dependent components.
thanks @donaldball - great food for thought
If you are using truncations to clean your DBs for testing, do you therefore have jobs/helpers to seed your database if you need some sample data for later tests? Has this proved particularly time consuming to do?
I strongly prefer to establish the givens for each test in the preamble. When I find I need many helpers to create the state I need for a test I view as a sign that I should probably look to simplify, perhaps by introducing an abstraction
@virmundi: Sure, if you have a question, just ask! You might also get a better response in #C050AN6QW, but here is just fine too
Hi, this is i am again. My problem is how to enable http2 to my project, that use jetty server. I think i can not add param --add-to-startd=http2 becouse my project use jetty like internal entity, i have defined dependency in project.clj, and in this way, my project use already compiled jar file from .m2/repository/org/eclipse/jetty/jetty-server/9.3.8.v20160314 and becouse this i can not set my own params to enable http2. Maybe someone already configured jetty to use http2 in projects? How i can do this?