1. How does config injection differ from method or constructor injection?

Config injection is an extended form of method and constructor injection. It intends to improve the UX of the code by hiding common and environmental concerns. This reduction in parameters makes the methods easier to understand, extend, and maintain.

2. How do we decide what parameters to move to config injection?

The key point to consider is how the parameter relates to the method or constructor. If the dependency is insignificant but necessary, such as loggers and instrumentation, then hiding it in the config improves the clarity of the function signature rather than detracting from it. Similarly, configuration coming from a config file is often necessary but not informative.

3. Why don't we inject all dependencies via config injection?

There are two significant issues with merging all the dependencies into one. The first is readability. Users of the method/function would have to open the definition of the config every time they wished to understand what parameters were available. Secondly, as an interface, users would be forced to create and maintain an implementation of the interface that could provide all of the parameters. While all config may come from the same place, other dependencies likely do not. The inclusion of the environmental dependencies is a little cheeky but their existence is almost ubiquitous, and their duplication across every constructor would be really annoying.

4. Why do we want to inject environmental dependencies (such as loggers) instead of using a global public variable?

As programmers, we like the Don't Repeat Yourself (DRY) principle. Injecting environmental dependencies everywhere is a lot of repeating.

5. Why are boundary tests important?

I hope we can all agree that it's important to test. Part of the value of testing is through running the tests repeatedly and detecting regression as soon as possible. To minimize the cost of running the tests often, we need the tests to be reasonably fast and absolutely reliable. When tests depend on an external system, particularly one that we are not responsible for, then we are putting the value of our tests at risk.

Anything can happen to an external system. The owner could break it; the internet/network could go down. Internal-facing boundary tests are similar to our unit tests. They protect our code from regression. External-facing boundary tests are our automated way of documenting and ensuring that the external system does what we need it to do.

6. What are the ideal use cases for config injection?

Config injection can be used in the same situations as constructor or method injection. The key deciding factor is whether the dependencies themselves should be combined and somewhat hidden by config injection and how that improves or detracts from the UX of the code.