I've used both intensively in work codebases and I've always been rather unimpressed with how Integrant plays out when it comes to authoring tests. I hear that people temporarily redefine defmethods? Or use with-redefs? With Component it's much cleaner to have test-specific behavior: just implement the given protocol and merge that impl into the test-specific System. With metadata-based extension, Component is lightweight, repl-friendly and can easily be instrumented with spec/malli/etc.

I guess I can see it. My experience writing tests doesn't generally focus on systems. I either write integration tests against the deployed system, or unit tests against things smaller that don't need components. I haven't felt this problem, but I can see how it could be an issue.

> just implement the given protocol and merge that impl into the test-specific System. but can't you do that almost similarly with integrant by deriving the test-component key from the parent service key and merging the test component into the system (as per https://github.com/weavejester/integrant/issues/81#issuecomment-615906828 comment)?

is not the case that you want to use a different config file for tests, swapping the integrant keys with your test components ... from the same author, this is what duct-framework does

https://github.com/duct-framework/duct/wiki/Configuration#duct-base-config

> but can't you do that almost similarly with integrant by deriving the test-component key from the parent service key and merging the test component into the system (as per https://github.com/weavejester/integrant/issues/81#issuecomment-615906828 comment)? Ah yes derive ... tbh I hadn't used it in a long time with Integrant, that was 2018 (other Integrant codebases didn't use it at all) I guess it works. But also that it's global state / indirection? I see some sort of contradiction between making more global state (more bespoke keys, globally registered) for making more local/specific variations (test-specific behavior)

I mean that is what namespaced keys are meant to solve, but I'm not trying to convince you to use integrant. Protocols etc. do provide a reasonable way to do mocking of whole systems.

you don't necessarily need derive, you can use vectored keys in your system map, {[:mock-email :email-sender] {:some-mock-arg true} .. instead of (derive :mock-email :email-sender)

https://blog.datomic.com/2023/04/datomic-is-free.html

Use #C03RZMDSH if you have questions…

Sorry, I thought it is interesting topic for whole community and worth to share the news license have changed

No worries at all! I just thought you didn’t know about it and there are some discussions there already.

I didn’t read any of this: is this Miller’s Law?

It always is