Fork me on GitHub
Charlie Briggs10:07:53

hello, we’ve recently started using specs and have a few questions regarding how to load them correctly say we have a namespace identity-provider and wish to have specs for identity-providers in a s_eparate file_, how would we go about doing that? We’re looking at putting the actual specs into a separate namespace as otherwise we’re having cycling import issues if we put our specs in a separate file/namespace (say specs.core, and named them as :core.identity-provider/id, :core/identity-provider would we need to then require :refer :all in consumer namespaces to ensure they’re loaded? Would it be more sensible to have a separate file for each entity specs, e.g. specs.identity-providers ? How would the ‘root’ object for the identity-provider look in that case (rather than using the name :core/identity-provider )

👀 3

You don't need to refer specs. Just requiring the namespace they're in will cause them all to be registered.


It's common to put data-describing specs in a separate namespace from code. As long as you require that spec namespace somewhere (anywhere, early in your execution path), those specs will then become globally available.

Charlie Briggs08:07:28

thanks for your response, so would it be common practise to load all specs in the server entrypoint, or a user.clj dev-namespaced file for use in the repl, rather than loading them in the code which is using them?

Daniel Stephens15:07:21

I don't know if this is at all good practice, but we have a ns per 'entity' for our specs to keep things readable, specs in one namespace can refer to others outside of their namespace by using fully qualified keywords (as normal), and then we have one ns which just requires them all. Those are all package together as one dependency, then anything that wants to use them just imports the dependency and requires that one namespace.

thumbsup_all 3