IoC Container + Unit Testing

Is it ok to use a container to create the objects that 开发者_如何转开发are going to be tested? Or should I build them manually?

---

Yes, it's okay and good and will keep kittens from being killed. Keep in mind that IoC containers are useful for three things:

1. object composition.
2. lifecycle management.
3. interception.

If you are in need of any of these three items, why not let a tool built for the job do it for you?

---

Yes and no.

You certainly can use one, but you shouldn't have to (Containers are great for composing complex systems, but in a unit test those complexities shouldn't be present).

Why are you considering it? Would hand-rolling the equivalent just be tedious (it always is), or would it be hair-pullingly difficult? If it's the latter then you're putting duct-tape on a problem.

---

Whichever way will give you the most accurate (closest to real use case) and yet lightest (free of all dependencies) instance of the unit to be tested. If you build your classes smartly - mostly not doing - you should be able to instantiate them without dependencies and therefore testing should be a snap. If you want to run tests against a group of classes at one time (to see how they work together...i dunno if many do this, though), then perhaps a factory (a design pattern which encapsulates instantiation) with a some stubs or drivers would do the trick.

http://wiki.answers.com/Q/What_is_stubs_and_drivers_in_software_testing

So yea, not a "container" per se, but potentially some other pattern or class you are assigning the sole responsibility of recreating the ideal testing situations.