I’m not sure where this would be the case. rule_plumbing can be defined wherever you seem fit. The controller has no idea which exact gateway it’s using. It just uses the one, which was put into the rule_plumbing data. The rule_plumbing being put into conn.private is just an example and a simple way to supply a controller with information, because all the data it receives (without global state) is the conn. Even the params in a usual def action(conn, params) come from a call like apply(controller, action, [conn, conn.params]). So you’ll hardly get around putting some information into the conn if you want to async controller tests with dependency injection.
It’s been some time, but I’m not sure how you expect it to work differently in regards to your problem. When a http request is handled the process, which is handling it, needs a way to resolve the abstract dependencies in the code into actual dependencies. It can either resolve them with knowledge available to the process already – basically all the information of the http request, or maybe the process dict, when we’re talking only about tests –, resolve it using information available to another process known ahead of time or non process based global or compiled state – e.g. hardcoded functions or modules being somewhere in your codebase. If this process handling a http request is spawned by phoenix or ace shouldn’t really make a difference in how those processes resolve their dependencies.
