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 spin up my
owin or now days dotnet core api's using the TestServer components that
allow you to test your services in memory and not having to host them on an
actual port.
In most cases my start up classes allow for a action to be injected into
either the owin or the dotnet startup class that wires up any dependency
overrides needed for the test, this action is run on the container before
the concrete components are wired up and this works fine as long as my test
overrides are marked as default and given a unique name.
Example:
class StartUp
{
public StartUp(): this(c =>{}) {}
public StartUp(Axtion<IWindsorContainer> customWireup) {}
public void Configuration(IAppBuilder app)
{
...
var container = new WindsorContainer();
customWireup(container);
container.Install(FromAssembly.This());
...
}
}
This has been working great however where I am now testing api calls that
call other API's I use the above TestServer components to create a fake api
endpoint. I don't know how well you know the Microsoft TestServer
components but these expose a HttpClient which is wired directly into the
pipeline. I then want to inject this into my IoC wireup instead of the real
HttpClient that would normally be used. Currently I can do this using the
above by my IoC wire up and the test wire up is getting a little messy. I
wanted to do the following but couldn't because the names where not unique
so I thought using a child container would help but alas it does not pick
up the child registration only the parent registration.
\\Installer
.Register(Component.For<SomeClient>().DependsOn(Dependency.OnComponent(typeof(HttpClient),
"someHttpClient")))
.Register(Component.For<HttpClient>().UsingFactoryMethod((kernal, model) =>
{
var config = kernal.Resolve<ISomeConfig>();
return new HttpClient { BaseAddress = config.Endpoint };
}).Named("someHttpClient").LifestyleSingleton())
\\Fixture
c.Register(Component.For<HttpClient>()
.UsingFactoryMethod((kernal, model) => fakeServer.HttpClient)
.Named("someHttpClient").LifestyleTransient());
I had a quick look at the IHandlerSelector but this looks like it is going
to create a lot of cruft when setting up each test. Has there been a
decision on the child containers? I am not sold on using child containers
but I am looking for anything that would simplify both the start up IoC
wire up where my tests impose as little impact on the code as possible and
simplify providing test specific component implementations.
Thanks,
Matt
--
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to castle-project-users+unsubscr...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.
