In general, if you are doing some form of TDD, and wanted to write isolated tests, I would recommend against wiring up a container to do your testing. You would want to eliminate the container from your unit tests completely.
So if you wanted to test the controller, you would do something like:
var sut = new DepartmentsController(new DepartmentRepositoryTestData());
This assumes you do want to have a concrete test class for IDepartmentRepository in lieu of using some sort of mocking framework.
If this is more of an integration test, and you DO want to wire up a container to test interaction between classes, then this would be the responsibility of your container registration code. You should have separate container registration for a testing story vs. a production story, so that services would resolve to different concrete instances based on context.
Edit
I think you are actually asking two questions here: one about routing and parameters, and the other about DI. I'm going to answer from the perspective of DI.
You said this:
For this abstraction (interface arg for the Controller constructor) to be of any value, though, there has to be multiple classes that implement that interface, right?
You are saying an interface/abstraction is only useful if there is more than one implementation? I think this is a matter of opinion, but many people who use DI create interfaces to promote loose coupling, even if there is only one (production) implementation. Often the second or subsequent implementation is a mock.
This could be a "test data" class and a "production data" class, or it could be a "California Pizza" class and a "New York Pizza" class, or California, New York, Chicago, and Italy classes that all implement IPizzaPie.
But somebody somewhere has to be the traffic cop that says: "Instantiate the California class" or "Instantiate the New York class" etc.
That's my question: who/where is this traffic cop (class instance decider), and how do we tell it which class to pass?
I think what you are looking for here is called an Abstract Factory. You can register multiple instances of an interface, and then create a factory that chooses the implemention based on some criteria.
Good article on the subject: http://blog.ploeh.dk/2012/03/15/ImplementinganAbstractFactory/
Edit #2
The code you posted in your last update is responsible for resolving the right controller for ASP.Net MVC. This is simply required plumbing for MVC to work using DI.
You are trying to return a specific implementation of a service based on some sort of context. This is generally done with an abstract factory, as I noted above. You would create a factory interface and inject it into the controller via the constructor, and then call it like this in a controller method or constructor:
IDepartmentRepository repo = _departmentRepoFactory.Create(myContext);
Any way you look at it, some code somewhere has to request that the container supply an implementation based on something (a string, an enum, an integer, etc.), and this is where the abstract factory comes in.