For what tests is the container in play?

We have seen those sorts of things blow up like that, but we are using the IOC configured exactly the way it would be in production (except for logging, which is changed to the console) so I guess for us when it blows up like that, we take it as time to fix something that really needed to be fixed anyway. It’s usually a one time fix, and something that needed to be fixed not only for the integration test to run, but also for the app to run. I guess that makes it seem like less of a pain for us (and it really doesn’t happen that often).

Anyway, explanation posted:
http://www.lostechies.com/blogs/joshuaflanagan/archive/2009/02/03/auto-mocking-explained.aspx

I’m taking your Dovetail Kool-aid away from you. For me, AMC is solving a problem I don’t have. I don’t feel any pain manually creating mocks in tests, and I don’t have to go through something else to go get a reference to them. Show me (in a post hopefully) a side-by-side comparison of with/without AMC and tell me why I should care.

What I was referring to was not AMC but using a Container to get “real” dependencies.

One problem we ran into was not that our container threw exceptions, but rather was not configured completely correctly for a test. A failure occurred because the wrong piece was wired up. We do have container tests, which caught it, but a whole bunch of tests that failed with a lot of noise. Have you seen that?

Those are integration tests, but we still don’t get a container involved. Just a local creation method will work, passing the exact dependencies I want involved.

As of yet, we haven’t had big problems with the IOC, at least none that weren’t explicitly catching issues that couldn’t be caught by just wiring up the container. For example, someone forgot to set up serviceoverrides, so we weren’t getting the right implementation and tests were blowing up trying to use incorrect implementations.

However, on the other hand, we had to spend a lot of time making sure that our integration tests painstakingly remove any data that they may put into the database, so that a failure in one integration test doesn’t cascade down into other ones using the same tables.

Really, the biggest downfall is the infrastructure we’ve had to wrap our tests in to make sure that they’re atomic in terms of the DB. It can (not always, but sometimes) make things a little bit annoying when writing a new integration test.

For instance, say you have a SqlUserRepository and an ActiveDirectoryUserRepository ?

At that point, you’re really only looking at an interaction test. Each of the other pieces are abstractions, so there’s no real point in getting them all up and going.

With test doubles, you can force your code down whatever path you like, without needing to set up your repository with the right data in the database, etc etc. This is assuming you’ve placed all your services behind interfaces, that is.