2010/9/23 Jason Meckley <[email protected]> > I don't see a need to subclass the container. > > tests involving the container are usually integration tests. making > sure i can resolve a component, or a feature works. >
it depends, to be honest, I don't feel useful the distinction between Integration Tests and Unit Tests... For me, tests are specifications, and specifications may be defined with real dependencies or with mocked/stub dependencies. There is one distinction that is useful, slow and fast tests. Slow tests usually are slow because they interact with an outside system, like db tests, or testing a webservice, or some tests that executes UI things like Selenium or Watin... A test involving the configuration of the container should not be so slow, but I think we can argue this. > on the rare occasion I inject the kernel into a component I mock > IKernel. > This is a bad practice, you can use the TypedFactoryFacility or a factory implemented in the same assembly of the container, you don't need a reference to the container. > there should be very few references to the container, > I agree with this point > so all in all > the number of tests involving the kernel/windsor should be minimal. > I am not sure about this point and this is the interesting point of this thread, where is the specification of what should be registered in the container or how is registered? How we can ensure this? > > installers are for registering components, facilities are for > extending the functionality of the container. > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
