I am running TDD on an ASP.NET MVC web app.
Is it standard practice to create integration tests to demonstrate the correct instantiation of a type via the DI container (in my case Castle Windsor)?
If so, would you mock out the container, or simply use it as is?
Or... is this simply not done for some reason?
Thanks.
The term Test in Test-Driven Development is usually interpreted to mean Unit Test, not Integration Test, so in a pure TDD process I wouldn't consider it standard practice to write and run integration tests of any kind.
This doesn't mean that it's not worthwhile to write and run integration tests - it's just not considered a standard practice of TDD. However, if you expand the scope a bit to encompass agile development in general, most agile organizations consider it a standard part of their practice to maintain and run automated acceptance tests.
Integrations tests like the ones you ask about would fit nicely into this type of process. You may not want to do it very often on your development machine, but still have your Continuous Integration (CI) build, or at least a daily build, do it (dependening on complexity).
When you view them as acceptance tests it makes most sense to let your DI Container resolve the entire stack as it's supposed to be - that is, no mocks would be involved in this case: you have to test the real deal.
The bottom line, however, is: if it works for you, do it. Agile/Lean Development is not about dogma - it's about constantly seeking out and applying the techniques that makes your team most productive. While it can be valuable learning from other people's mistakes and successes, you must ultimately experiment and measure what works best for your team.