Clojurians Log v2

@weavejester: Have you ever wanted or wished for something like with-redefs but for integrant keys? Thinking for the testing case, where you want to stub out a component in a system. I do this currently by defining a new ig/init-key for the stub, meta-merging a test profile over the system with something like (let [system (ig/init (meta-merge main-system {:<http://service.to.be/stubbed|service.to.be/stubbed> (ig/ref :my.test/stub)}] ,,,)) However this requires a bunch of boiler plate defmethods especially when those components then need to contain a shared dep for the test to use; e.g. a atom/promise/core.async channel etc… Then the test needs to look into the system to pull out the references to those extra deps that it wants (e.g. the shared channel) which is pretty gross. It’d be nice to be able to do something that let me just define those stub deps in my local scope, rather than have to use defmethods etc. Any thoughts on this, or alternatives?

Not quite sure how such a thing might work in practice

hmmm actually I think I might have thought of a way to do it without requiring integrant features

@rickmoynihan I don't have any thoughts on stubbing out defmethods, except maybe by using :default or derive. I'd be interested in what you come up with, however.

Scratch that it turns out it doesn’t work 😞 I’m not sure this is possible without integrant changes… I think the nicest for a user might be for integrant to honor metadata on the RHS of a key that effectively says skip the defmethod constructor and use the value that’s here instead.

Hmm... I'd need to think about that.

yeah it definitely needs some thought but was thinking something like this:

(let [stub-chan (async/chan)
      system (ig/init (meta-merge main-system
                                  {:<http://service.to.be/stubbed|service.to.be/stubbed> ^:ig/stub (mock-service stub-chan)}] ,,,))

The problem with defmethod and derive are that they’re static.

The other option would be to have ig/init take an additional overrides argument map… or have a new ig/init-with-stubs

that takes a map of stubs

Is stubbing multiple services really that useful? As opposed to just defining a global fake service to use?

e.g. :duct.database.sql/hikaricp vs. duct.database.sql/stub

I think it depends. The test here is an integration test; a large part of what it is testing is the base system config is wired up ok.

so yes, I can do that… but it’s a complex system; and once you start removing keys from the system and replacing them with others it becomes very hard to verify the test is right

I have considered doing this but it gets messy as you have to replace the ig/refs to the key; using something like clojure.walk.

Though I guess I can probably implement a generic swapper that walks and replaces keys easily enough… though for the test case it’s often useful for system values to come from a closure rather than config… Actually this might work with a single defmethod like:

(defmethod ig/init-key ::test [_ test-instance]
  test-instance)

What about building something that simplifies (with-redefs [ig/init-key ...] ...)?

:thinking_face:

Like: (with-methods [ig/init-key {::foo (constantly {:a 1})}] ...)

So an equivalent of with-redefs but for multimethod keys.

Then it wouldn't have to be tied to Integrant at all.

That’s an interesting idea

Should be quite easy too

Will try

thanks a lot

np