Onde está acontecendo a "mágica" quando um Controller instancia a implementação correta da Interface na Web API DI?

Parece-me que em algum lugar um coelho está sendo puxado de um chapéu quando se trata de DI em Web API Controllers.

Eu entendo que: 0) O Controller em um projeto de API da Web pode ser chamado com várias classes a serem instanciadas, todas implementando a interface da qual o Controller depende. por exemplo, com este código do controlador:

private readonly IDepartmentRepository _deptsRepository;

public DepartmentsController(IDepartmentRepository deptsRepository)
{
    if (deptsRepository == null)
    {
        throw new ArgumentNullException("deptsRepository is null");
    }
    _deptsRepository = deptsRepository;
}

... "deptsRepository" pode ser uma classe que implementa IDepartmentRepository e recupera dados de teste, OU pode ser uma classe que implementa IDepartmentRepository e recupera dados de produção, OU (etc.)

1) A API da Web decide qual Controlador é chamado com base no URI que o cliente chama e que a API da Web decide qual método nesse Controlador é chamado com base em qual tipo (GET, POST) etc. é e quais argumentos, se houver, são passou com ele.

2) O Castle Windsor intercepta esse controle automático dos controladores com seu próprio mecanismo de roteamento de substituição.

O que eu não entendo é exatamente onde o desenvolvedor injeta a classe concreta que implementa a interface esperada pelo Controller. IOW, se eu quiser executar a classe que extrai dos dados de teste, onde adiciono código para especificar isso? Eu acho que estaria em algum lugar no Global.asax.cs, algo como (pseudocódigo):

// Use test data for now
DeptsControllerClass = TestDataClass;
//DeptsControllerClass = ProductionDataClass;

IOW, onde se especifica: "Desta vez, quero que você injete ESTA classe concreta que implementa a interface necessária"?

questionAnswers(1)

yourAnswerToTheQuestion