Hi Ken,
I just stumbled on this trying to achieve something similar to Xi. Long
have gone the days where I do any specific unit testing instead opting for
outside in bdd style testing on my api's and only using smaller unit tests
to flesh out the more complicated components. With that my tests
Hi,
so if I understand correctly, you would like to:
1. test if your registrations, etc - are OK
2. use the existing container to get classes to tes, so it essential
auto-wires-up the dependencies, but you replace them with mocks when/if you
need it
If the above is correct, I had solved it by:
1.
The parent/child containers were never properly designed. The thing just
fell into place as is. It's really not recommended, unless you have deep
understanding on the inner workings of windsor. Ken's suggestions are more
friendly for what you're trying to accomplish.
On Thu, Sep 7, 2017 at 4:32
You can use a IHandlerSelector to override specific registrations (see
http://kozmic.net/2009/12/07/overriding-generic-componentrsquos-resolution-in-castle-windsor/
for an example of using a selector, yours would be different of course)
As a side comment - testing the configuration is a novel
Hi Ken,
My scenario is, I want to use DI in my unit test, and I need to override
some dependency with mock instance.
I know some people say we should not use DI in unit test. But I think unit
test can also be used to verify if the DIs are configured correctly.
I would also like to learn a
So much time since I last touched child containers...
Once resolution went up to the parent container it would not go back to
resolve from the child as the direction is one way.
The right question to be answered is "what is your scenario?" Experience
shows that more often than not, a