Testing a Mix app with ExUnit: changing config values set at compile time

[tompave]

Thanks for the reply

@OvermindDL1

Near the top of my config/config.exs in my root project I have a few lines of:

import_config “../deps//config/defaults.exs"
import_config "../deps//config/#{Mix.env}_defaults.exs”

So, the library’s config.exs is loaded only if the developers of host applications import it correctly. I imagined this was possible, but it doesn’t seem very reliable. Still, good to know!

@OvermindDL1

The Application.env functions are fast, like really fast, do not worry about accessing it being slow. Configs stored dynamically in ETS are also blazing fast, you’d be surprised just how fast ETS is, feel free to access it on-demand.

(…) ETS is fast, designed to be fast.

Ok, thanks. Good to know

@OvermindDL1

For a Caching layer though I’d make it a configured process PID or name, depending on what process is started there it either caches or it does not, it can even be swapped out in real-time without anything else in the system knowing or caring.

(…)

Another nice thing about if you were to make a dedicated process for connecting and it was either caching or not (and could be swapped at runtime) is that mocking it would then become dead-simple.

I’m not sure what do you mean with this.

At the moment the cache is an ETS table created with [:set, :protected, :named_table, {:read_concurrency, true}]. It’s wrapped in a supervised GenServer started with the application.

Writes to the cache are go through casts to the owner process, so that they’re serialized (they’re going to be infrequent or, at best, in short bursts).
Reads, on the other hand, are executed in the invoking process, to minimize the data transferred between processes. I’m vaguely aware that an ETS table is actually a process itself, but I’m trying to support high levels of read concurrency and I’ve read that this approach is better than reading through GenServer.call(table_owner_pid, {:please_read, :my_key}).

Is this what you’re referring to? Or are you suggesting another process that either proxies to the cache or goes directly to Redis? And then I would swap this process if needed?

@OvermindDL1

For the code generation style you can test it, but you need to make more than one testing environment and be sure to test using them all (via alias’s for example).

Ok, that’s interesting. I can think how I would do it by setting MIX_ENV in the terminal. Can you give me an example of how you’d do this with alias please?