This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-18
Channels
- # admin-announcements (1)
- # aleph (3)
- # beginners (20)
- # boot (9)
- # cider (74)
- # clara (1)
- # cljs-dev (28)
- # cljsrn (15)
- # clojars (32)
- # clojure (149)
- # clojure-dusseldorf (3)
- # clojure-italy (6)
- # clojure-nl (3)
- # clojure-russia (20)
- # clojure-uk (5)
- # clojurescript (133)
- # core-async (2)
- # cursive (19)
- # datomic (24)
- # devcards (1)
- # funcool (100)
- # hoplon (48)
- # keechma (1)
- # kosmos (7)
- # ldnclj (3)
- # leiningen (3)
- # luminus (16)
- # off-topic (8)
- # om (103)
- # onyx (47)
- # pedestal (3)
- # proton (7)
- # re-frame (13)
- # reagent (11)
- # ring-swagger (1)
- # specter (6)
- # testing (12)
- # untangled (24)
- # yada (32)
Hello everyone. I kinda miss having factories(as factory girl in Ruby) in clojure, I didn't even have to really write in the database and this felt like an advantage, how would you approach that in clojure?
You might enjoy using the generators from test.check
thiagofm: personally, i don't think mocking actual services is a very good idea, since you might be missing some important integration tests
lmergen: I'm reading articles that support your point, but in the end I think it's really about tradeoffs, it makes things a bit easier to write
When working with services, I prefer to write a protocol, write a impl that hits the service, and an integration test that actually interacts with the service. For other tests, I’ll reify an impl that provides the behavior I need to exercise the conditions about which I care.
The utility of this approach is bounded by the complexity of system’s interaction with the service tho. Works great for a key-value store, not so well for a relational database unless only used in narrow ways.
@donaldball: do you anything explaining this approach in detail? Sounds good