This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-24
Channels
- # adventofcode (6)
- # announcements (4)
- # aws (21)
- # babashka (36)
- # beginners (58)
- # calva (3)
- # cider (2)
- # clj-kondo (21)
- # clojars (3)
- # clojure (35)
- # clojure-dev (4)
- # clojure-europe (5)
- # clojure-nl (8)
- # clojure-uk (8)
- # clojuredesign-podcast (7)
- # clojurescript (10)
- # core-async (3)
- # data-science (2)
- # datomic (2)
- # defnpodcast (11)
- # duct (4)
- # figwheel-main (1)
- # fulcro (34)
- # graalvm (12)
- # graphql (4)
- # joker (14)
- # kaocha (1)
- # midje (1)
- # off-topic (5)
- # pedestal (1)
- # re-frame (3)
- # reagent (4)
- # reitit (1)
- # shadow-cljs (4)
- # testing (12)
Is there a recommended approach to testing namespaces that use 3rd party libraries, such as a client to connect to a external resource, to "mock-out" that client? Say, for example, I have a function that uses the Elasticsearch Client (via interop), and I wish to test that function and mock out the call to the ES client, is there any recommendations?
@dharrigan You have to have a layer of abstraction in there somewhere to be able to mock it. Either a wrapper around the interop so you can mock the wrapper, or a protocol-based wrapper so you can have a test implementation of the protocol (although that's frowned upon by some people if you only have your single production implementation and are using the protocol purely for testing).
I see, - doesn't seem that wrong to use a protocol, it's to achieve something, i.e., to test 🙂
Well, protocols are meant for when you have multiple (production) implementations and want fast dispatch based on type...
with-redefs
🙂
If you're using Component, you just build your system-under-test with test/mock versions of some components.
A mocking framework makes sense in an OOP language, not so much in a functional language.