Reputation: 17392
Is there a not too dirty way to detect at runtime, whether the code was started with lein test
? I just want to select a different redis database, so solutions like environ or using different resource files seem to be a bit overkill.
For example, leiningen automatically enables the test profile, but I haven't found a way to get a list of currently enabled profiles.
Upvotes: 4
Views: 560
Reputation: 2364
I found a way with Cprop. Set a var in your "env/{test|prod|test}/config.clj" file:
(System/setProperty "lein.profile" "dev")
then you can read the value:
(require '[cprop.source :as source])
(str "from-system-props: >> " (:lein-profile (source/from-system-props)))
other option is to search for the key ":conf" in the system-props:
:conf "test-config.edn"
because the config file changes according to the profile.
Upvotes: 0
Reputation: 1389
It might seem like overkill, but component for instance is invented for exact usecases like this. Or dependency injection in general.
I know that feeling, it's just a private project, no need for difficult stuff etc. Thats why I put together my own template so that all I need to get started is run lein new ...
This is my solution to circumvent the "just want to select a different redis database" usecases.
Edit It is a template for a web framework: https://github.com/sveri/closp but a lot of these parts are not specific to web dev, especially the components part: https://github.com/sveri/closp/tree/master/resources/leiningen/new/closp/clj/components
There is also an integration test where I make use of test components specifically: https://github.com/sveri/closp/blob/master/resources/leiningen/new/closp/integtest/clj/web/setup.clj
Upvotes: 1
Reputation: 13185
There is no simple way to do it. Neither lein.test
nor clojure.test
expose such information. Even if you find a way to hack into some private var of lein test or clojure.test
and check it to determine if your code is run as part of lein test
.
However, it would have a very big issue: your production code would need to require
testing library code (e.g. clojure.test
) or even worse your build tool code (lein test
plugin code).
You might try to define such configuration var (dynamic or not) in your production code and set it in your tests using fixtures.
The best solution would be to configure your application dynamically based on the external variable like system property or environment variable (e.g. by using suggested environ
). This way you can have as many different configuration sets as you need (e.g. prod vs unit test vs integration test vs performance tests and so on) and not just two (prod vs test).
Upvotes: 1